search

signalapp / Signal-Desktop

A private messenger for Windows, macOS, and Linux.
https://signal.org/download
GNU Affero General Public License v3.0
14.51k stars 2.63k forks source link

Please provide a distribution-neutral AppImage for Linux #1758

Open probonopd opened 6 years ago

probonopd commented 6 years ago

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

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:

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 commented 6 years ago

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

dmhowcroft commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

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 commented 6 years ago

electron-builder can build AppImages.

willwh commented 6 years ago

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 commented 5 years ago

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

dmhowcroft commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

stratacast commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

Great work @kevinsarsen https://github.com/signalapp/Signal-Desktop/pull/3055 I really hope @scottnonnenberg-signal has some time to decide about this.

probonopd commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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 commented 5 years ago

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

shoogle commented 4 years ago

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

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 commented 4 years ago

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

It's not even that old, but it refuses to work. Lovely. :roll_eyes: 2019-10-29-172208_734x146_scrot

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 commented 4 years ago

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

ctrlcctrlv commented 4 years ago

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

dmhowcroft commented 4 years ago

@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 commented 4 years ago

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. :roll_eyes:

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 commented 4 years ago

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

dmhowcroft commented 4 years ago

Just got the upgrade warning directing me to the Signal download page which only has instructions for DEB-based systems. Still no AppImage, still no RPM.

@scottnonnenberg-signal, please let us know what needs to happen to get this support--maybe we can help!

almereyda commented 3 years ago

Asides from technical considerations between AppImage, Flatpak, Snap, RPM and DEB, I am wondering about the political perspective of the Signal developers on this subject.

As far as I know, Signal wants to be a trustable and recommended platform for private and public, end-to-end encrypted messaging. Since a plethora of alternatives exists, and the double ratchet has meanwhile also found its way to What's App, people rely on the network effect to choose which platform to use.

Often it is the recommendation of a privacy-aware person (jargon computer nerd), that helps create new Signal installs worldwide, following Edward Snowden's example. In turn these people are often running Linux themselves, and would also promote it to their peers where feasible. Not supporting this user base on the Linux desktop, and reducing the diversity and variety of Linux to mere Ubuntu, is a drawback against Element and other encrypted messengers.

This issue is open for almost three years, and messaging skyrockets. Linux grew well-tested and hardened, because it combines the efforts of many on multiple platforms. Since distribution formats for supporting all of them exist, it remains to ask what is blocking the decision here to do so?

zenny commented 3 years ago

A real case scenario why an AppImage is essential to build for applications like this as in OT, not because of political reasons, but due to the userbase.

A friend in Germany who is aggressively concerned about the security, but has no knowledge of Linux wanted to install Signal to quench his insatiable thirst for "privacy". He went amok with the installation instructions and wrote back to me . Methought if there would have been an AppImage, I could just point him to the download link and ask to make it executable and run. That was not the case. Thus, I landed to this issue by @probonopd.

If Signal is something that should be handy with everyone who uses linux, an AppImage would be more than useful. However, I build my own Signal from the source, but not everyone is able to do so.

I have a support for what https://github.com/signalapp/Signal-Desktop/issues/1758#issuecomment-712407448 stated above.

Cheers and stay safe.

kargaroc commented 3 years ago

This is super important now.

hasufell commented 3 years ago

I'm sorry to say this, but this ticket is deeply troubling.

It's also a bit embarrassing, because there has been a lot of praise about the quality of the Signal codebase and the cryptographic primitives in the past, suggesting Signal developers are aware of software security issues inside out.

Unfortunately, they don't seem to be aware of the intricacies of software distribution and that it's one of the major problems of security:

  1. ensuring the user gets a trusted binary
  2. ensuring that binary is up to date
  3. ensuring that dependencies of that binary are up to date (this is non-trivial and flatpak etc don't solve it)

If you put any relevance to your desktop users, you should make sure that linux users on all major distros can install and update Signal through their package manager.

If you don't, then I'm afraid you really haven't understood the relevance of software distribution in software security and users are better off using alternatives, even if they have worse code quality or design.

aspiers commented 3 years ago

As someone who previously worked for SUSE for many years, I entirely agree with the previous comment.

Having said that, AFAIK there shouldn't be anything stopping each distro from packaging Signal itself. It's actually more normal for downstream distros to do the packaging themselves rather than to rely on the upstream project to do it.

In fact SUSE's Open Build Service (OBS) already provides experimental packages for openSUSE and Fedora, although in my experience they have some annoying bugs, at least when run on openSUSE Tumbleweed. It probably wouldn't be hard to extend this package to build on other Linux distributions too, since OBS supports many distros.

probonopd commented 3 years ago

ensuring the user gets a trusted binary

The only way to ensure this imho is to have the user download the Signal binary from the upstream Signal website, or else you can never know what the distribution has changed or whether the exact version of libraries the distribution has compiled it against has been tested by the upstream authors.

Even very reputable distributions (like Debian) have changed software in the past to an extent the application authors did not agree with.

hasufell commented 3 years ago

If you're weighing the competence of distro developers against the competence of upstream developers wrt software distribution, dynamic linking, shipping updates and communicating CVEs to users... I'd pick my distro any day.

They do it every day since decades, have developed tools, processes and policies to enforce quality, correctness and swift communication in case of vulnerabilities.

However, an upstream maintained ppa/rpm repo can be a solution too. Better than an unknown 3rd party repo for sure.

Ideally, upstream developers, who care about linux desktop experience should ultimately work with distro developers, trying to push them for including their software and offering help to mitigate problems. Some do that. It works. It's the correct way.

probonopd commented 3 years ago

I prefer a single binary file coming from, tested and supported by, upstream. Because I can wait like, forever, for Debian Stable to ever get the lastest and greatest Signal.

hasufell commented 3 years ago

If you're talking about a static binary, then that's probably one of the worst ideas wrt security. I haven't seen a single developer, who recorded the entire build plan (including transitive deps) of the binary and then did periodic CVE checks to identify whether one of the deps are vulnerable and then rebuilt the entire binary and shipped it in time every time that happened.

With dynamic system-wide linking, this is much easier and distros have the appropriate tools and manpower to identify and update this in a timely manner.

Of course, if you don't personally care about that, then that's fine, but it isn't a strong argument for security.

pepa65 commented 3 years ago

I have started advocating for wide Signal uptake, but this issue is seriously undermining trust. ARE ANY PEOPLE IN CHARGE EVEN PAYING ATTENTION TO THIS?? This is the golden opportunity for all the refugees from Whatsapp, but they have to be able to install a desktop client! A webclient would be sufficient as well, but you can't just supply something for the smartphone only, that is a losing proposition!

shoogle commented 3 years ago

If you're weighing the competence of distro developers against the competence of upstream developers wrt software distribution, dynamic linking, shipping updates and communicating CVEs to users... I'd pick my distro any day.

That might be true for major distro packages (e.g. Firefox), but the smaller and medium-sized projects are packaged by volunteer maintainers, not by anybody "official" at the distribution. So it's not really the distribution that you are trusting so much as a random person.

If you're talking about a static binary, then that's probably one of the worst ideas wrt security. I haven't seen a single developer, who recorded the entire build plan (including transitive deps) of the binary and then did periodic CVE checks to identify whether one of the deps are vulnerable and then rebuilt the entire binary and shipped it in time every time that happened.

Applications on Windows and macOS (including Signal) bundle their own private copies of libraries and the world has not ended. Besides, this is not really relevant for Signal because it releases core updates so often. As long as Signal core is built against the latest libraries then users only need to wait a few days for the next core update to get the latest library as part of the AppImage.

BTW, where do you think libraries inside AppImages come from? (Spoiler: it's from the distros.)

aspiers commented 3 years ago

ensuring the user gets a trusted binary

The only way to ensure this imho is to have the user download the Signal binary from the upstream Signal website, or else you can never know what the distribution has changed

This is not true. Every reputable distro makes it easy to find out exactly what the distro has changed. For example, a simple search and a few clicks gets me to this page, which shows the exact three patches which are applied to create the openSUSE Tumbleweed build of Signal, and a myriad of other details about how the package was built.

Additionally, openSUSE and other prominent distros have made significant progress in recent years on providing Reproducible Builds, which is especially relevant to apps like Signal.

or whether the exact version of libraries the distribution has compiled it against has been tested by the upstream authors.

Even very reputable distributions (like Debian) have changed software in the past to an extent the application authors did not agree with.

Yes, there is always a tension between upstream and downstream testing. There are usually pros and cons to both. But I strongly agree with @hasufell here who clearly knows what he's talking about. Static binaries with huge amounts of dependencies introduce plenty of problems which can be mitigated to some extent if upstream are really good at tracking security updates and the quality of their CI. Many upstreams are not but one would hope that Signal are, given the importance of security to their code.

aspiers commented 3 years ago

Applications on Windows and macOS (including Signal) bundle their own private copies of libraries and the world has not ended.

Hah, that has been a common cause of bloat and security issues in Windows for many years.

Besides, this is not really relevant for Signal because it releases core updates so often. As long as Signal core is built against the latest libraries then users only need to wait a few days for the next core update to get the latest library as part of the AppImage.

Don't get me wrong, an AppImage would be a lot better than nothing. If the build process is transparent, verifiable, reproducible, and published regularly, then great. IMHO it still wouldn't be as good as distro-native packages, but I'd happily take it.

Anyway, we probably shouldn't turn this issue into an AppImage vs. native packages debate, and I apologise for already contributing to that tangent. But the Signal team should think carefully about how to provide Linux support properly.

BTW, where do you think libraries inside AppImages come from? (Spoiler: it's from the distros.)

  1. Not necessarily, they could be building from source.
  2. Even if it's from the distros, that's irrelevant because AppImages subvert the distro build/test/release lifecycle, so e.g. if you perform a normal update of all packages on your system, you could still have a vulnerability in your AppImages.
shoogle commented 3 years ago

@aspiers, what you say is true, but I was just pointing out that the problems with AppImages are not as serious as they have been made out to be, and distros do not provide the perfect solution as has been claimed (because it is not the official distribution that does the packaging but a random volunteer). In my view it would be better to get Signal from the Signal developers, using libraries tried and tested by the Signal developers, rather than from a random contibutor to some distribution.

pepa65 commented 3 years ago

The nice thing about an AppImage is that it works on all distros/installs as long as it's the same architecture. I just followed the earlier mentioned page, combined with Signal-Desktop's Contributing page and managed to build an AppImage that works (on amd64/x86_64)!

I replaced Andrea Fortuna's page's yarn icon-gen by the Contributing page's yarn build:webpack and before doing yarn build-release I edited the package.json file to add the AppImage target as described on Andrea's page. It would be great if this project could build this, because we have to trust them already anyway.

But the result of my Signal-1.39.4-beta.1.AppImage build can be downloaded here for those that would like to test it (it's147 MB).

To test it on your system, download it in the browser, make the file executable and click on it.

aspiers commented 3 years ago

@shoogle commented on January 10, 2021 1:38 PM:

@aspiers, what you say is true, but I was just pointing out that the problems with AppImages are not as serious as they have been made out to be, and distros do not provide the perfect solution as has been claimed (because it is not the official distribution that does the packaging but a random volunteer).

Neither is perfect, it is true. Like I said there are pros and cons to both, and I'd be very happy if Signal provided an Appimage.

In my view it would be better to get Signal from the Signal developers, using libraries tried and tested by the Signal developers, rather than from a random contibutor to some distribution.

Well, having worked with many of those random contributors for 25 years, and being one myself, I have a slightly different opinion, but of course everyone's free to have their own preferences ;-)

mdedonno1337 commented 3 years ago

But the result of my Signal-1.39.4-beta.1.AppImage build can be downloaded here for those that would like to test it (it's147 MB).

To test it on your system, download it in the browser, make the file executable and click on it.

Nothing against you, but I'm sorry, I will not download a binary from the web and run it locally, in particular if it's hosted on this type of site.

The best (better?) way would be to add a CI job here on github, producing all the files (.deb, appimages, ...).

I have a gitlab CICD job to do that on my side (done yesterday), and will be more than happy to contribute back in this repo (and maintaining it) iif the maintainers of Signal are OK with it (from a philosophical point of view).

pepa65 commented 3 years ago

This is exactly what I am driving at. We need an AppImage file as an asset on THIS project. Thank you for having done the work already to make this happen. They only need to add "AppImage" as a target besides "deb" and we're good.

mdedonno1337 commented 3 years ago

At the moment, if I dont mistake, there is only the sources that are present in the Release page; and this was exactly why I had to compile it my self.

I think that all targets shall be present in the release page, including the .deb, .appimage, .exe and the sources files (I dont know about mac, I dont have one).

mdedonno1337 commented 3 years ago

@aspiers

  1. Even if it's from the distros, that's irrelevant because AppImages subvert the distro build/test/release lifecycle, so e.g. if you perform a normal update of all packages on your system, you could still have a vulnerability in your AppImages.

Correct if you consider only your machine.

I think that the build shall be redone continuously, let say every day, even if no commit is done on the signal-desktop app. This will re-pull the update from upstream for the dependencies (from source, distro, whatever), hence having the same update as the "hard installed" versions (via any type of package manager).

I agree that this will not ensure that your old version on your computer is up-to-date, obviously, but will at least ensure that the downloadable version on the release page is up-to-date. There is, as far as I know, no good solution to manage the update of appimages at the moment.

mdedonno1337 commented 3 years ago

because of the high traffic on the issues page, should we ping someone in particular ?

andrewmackrodt commented 3 years ago

The best (better?) way would be to add a CI job here on github, producing all the files (.deb, appimages, ...).

This would be my preferred solution as well.

In the meantime, for anyone who wishes to compile their own AppImage but don't have the correct node version installed, here's a copy/paste docker snippet to create an AppImage from the latest master HEAD in your ~/Applications directory:

docker run --rm -it -v $HOME/Applications:/app -w /app node:12.13.0 bash -c "$(cat << 'EOF'
    set -euo pipefail
    git clone --branch=master --depth=1 https://github.com/signalapp/Signal-Desktop.git /tmp/Signal-Desktop
    cd /tmp/Signal-Desktop
    sed -i -E 's/ {8}"deb"/        "appimage"/' package.json
    yarn install
    yarn build-release
    cp /tmp/Signal-Desktop/release/Signal-*.AppImage /app/
    uid=$(ls -nd /app | awk '{ print $3 }')
    gid=$(ls -nd /app | awk '{ print $4 }')
    chown $uid:$gid /app/Signal-*.AppImage
EOF
)"