search

signalapp / Signal-Desktop

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

Feature Request: Flatpak for Linux #1639

Closed comzeradd closed 3 years ago

comzeradd commented 6 years ago

It would be nice to have the app distributed as a Flatpak.

It would make installation so much easier (and more secure), even for APT distributions.

scottnonnenberg commented 6 years ago

What do you know about update mechanisms for flatpak? Automatic updates? Or perhaps just notifications of new versions and easy manual upgrade?

vrutkovs commented 6 years ago

Flatpak apps can be updated automatically, rolled back and checked for updated, very similarly to git. Every application can be installed from a remote repo, so every time the app is updated remotely the users would pull the changes and can update the app easily. Each change has its own commit hash, so it can also be easily rolled back. Flatpak repo can have multiple branches (i.e. "master" and "stable"). The app can be packed in a bundle and distributed without a repo.

I'm running Signal in flatpak using released .debs, see https://github.com/vrutkovs/flatpak-signal

ghost commented 6 years ago

If a tarball distribution is provided, I'd be willing to put the time in to have it included in the OpenBSD ports system as well.

scottnonnenberg commented 6 years ago

Can someone point me to some documentation on flatpak auto-update mechanisms?

vrutkovs commented 6 years ago

Flatpak is using ostree to distribute updates, its model is very similar to git. Here Flatpak maintainer Alex Larsson wrote a great blog post about the contents of the repo.

From user perspective it looks like this:

It shows that commit a24ca2533d206e192e6e4a99fbc32bc1b075164826d0d725062343ca5d6ef6e8 is installed.

commit 6c51a0f75e5402cd3cd6af7b48758d2bc1ed5ed961cec25145de23fce5ed11a2 Date: 2017-11-01 22:00:16 +0000

Nightly build of Signal, Wed  1 Nov 22:59:37 CET 2017

Name: org.signal.Desktop
Arch: x86_64
Branch: master
Built with: Flatpak 0.9.99

... $ flatpak --user update --commit=6c51a0f75e5402cd3cd6af7b48758d2bc1ed5ed961cec25145de23fce5ed11a2


* Pull the latest commit from the repo:

$ flatpak --user update org.signal.Desktop


(or `flatpak --user update` to pull updates from all remotes)

Feel free to jump in at #flatpak on freenode and ask questions
garrett commented 6 years ago

There's already been a lot of discussion of Flatpak above. One thing that's lacking is the experience from using Flatpak on the desktop.

Advantages of Flatpak

A desktop centric view of installing a Flatpak app

Let's use the Blender app on Flathub as an example.

On the Flathub website, the app is styled like a tile, like this: screenshot-2017-11-7 applications hosted on flathub 1

...It's just a link to https://flathub.org/repo/appstream/org.blender.Blender.flatpakref — and you can link it from other places (like here on GitHub), even if it's on Flathub. In the case of Signal, you could publish on Flathub (or elsewhere) and link from Signal.org.

After clicking in the link, the flatpakref is immediately loaded by the app store / software center (GNOME Software in this case). It's basically just a friendlier version of the metadata provided in the flatpakref. It looks like this:

gnome-software-blender-flatpak

And it does have details on the same page, like the source of the Flatpak, the license, version, a link to the project's website, and place to leave reviews.

screenshot from 2017-11-07 10-06-31

After clicking install, it installs with a progress bar, and then same page has a "Launch" and "Remove" button.

Installation summary

It's basically a 2 click install process (click on website, click install to confirm in the software app).

And updating happens automatically in the same place with all the other app & system updates happen (which means there are also notifications when updates are available), at least in the case of GNOME and KDE based distros.

charlesjt commented 6 years ago

Signal-desktop is now available on flathub. By the directives of the store, OWS can request authorship and maintain the package.

signal-flathub

breznak commented 6 years ago

Is also snap "the other" format considered? But I think tarballs should be enough and leave rest to packagers

bermeitinger-b commented 6 years ago

The flatpak version runs fine but who is maintaining it? The deployed version is 1.0.35 whereas the newest version currently is 1.0.38. Is the code for building the package somewhere?

Also, from my understanding, flatpak supports branches, so one could use the development branch to always be bleeding-edge, if one wishes.

tvannahl commented 6 years ago

@bermeitinger-b The flathub release of Signal is maintained here.

lpar commented 6 years ago

Decided to give the Flatpak version of Signal a go. (Fedora 26.)

First tried installing from command line (flatpak --local). That worked, and I could run Signal, but I couldn't access any files to import my exported data from the old web app. I got an empty home directory instead. I tried creating a folder and then went looking for it, but couldn't find it anywhere on the filesystem using locate or find. Checked documentation and FAQs, no information I can find about where it actually puts your files. So, uninstalled all that and made sure flatpak list showed nothing installed.

Next tried Flathub. Clicked on Signal, went through the GUI installer. It installed an icon for Signal, but it wouldn't start. Investigated via the command line:

flatpak update
Looking for updates...
Required runtime for org.signal.Signal/x86_64/stable (org.freedesktop.Platform/x86_64/1.6) is not installed, searching...
Found in remote flathub, do you want to install it? [y/n]:

Told it to install the missing runtimes which the GUI installer hadn't bothered with. After that, I had a working Signal that could actually see my files.

So I think Flatpak isn't quite there yet as far as ordinary end users are concerned.

comzeradd commented 6 years ago

So I think Flatpak isn't quite there yet as far as ordinary end users are concerned.

I'm not a Flatpak expert, so I can't guess what went wrong with your installation but it worked really smoothly for me (Fedora 27). I just installed Flathub repo and all the apps, including Signal, are available through the Software app. I didn't have to open the terminal at all.

dephekt commented 6 years ago

What happens right now if Flathub's repo or build tools are compromised? Is Flatpak downloading the .deb package to my PC from signal.org and building it all locally? Is Flatpak checking for a valid OWS GPG signature on the download before doing its work? I'm just trying to understand how the trust changes in this scheme without knowing a lot about how Flatpak handles this. I've been using the Flathub distribution for the last few weeks and I've been operating under the assumption that trust with OWS is broken this way; I'd just like to know if that's right or wrong in a (mathematically) provable way.

This isn't intended to be an indictment on Flathub or Flatpak, but I trust the build environment and key holders of OWS more so than Flathub (primarily because I'm ignorant of how Flathub does their PKI and less so inre OWS) or my own machine, so if there's a way to maintain the developer trust still while using Flathub then I'm happy. If there is not, then I think it should be made very clear on the Flathub release that it is unofficial and not signed by OWS, since anyone using Flathub already but is not privy to this thread may not be aware of the security implications that what they're installing isn't bit-for-bit the same thing Moxie signed on their offline build system using his secure keys.

LivInTheLookingGlass commented 6 years ago

I have a strong preference against this. I don't want to have to install an entirely different distribution method just for one application.

comzeradd commented 6 years ago

I have a strong preference against this. I don't want to have to install an entirely different distribution method just for one application.

You don't have to. It's just another option for people who want to.

lpar commented 6 years ago

I've no concerns regarding FlatPak being provided as well as Fedora RPMs, but I thought it was being suggested as an alternative to providing native distro packages for all the distros.

deutrino commented 6 years ago

Linux Mint 18.3 now ships with native flatpak support, including full integration to their software installation manager (their equivalent of an app store) - which as a Linux user for over 20 years, even I use on occasion, if that's any indication of its usefulness to a broad spectrum of users.

tvannahl commented 6 years ago

There are many reason for me that are good reasons to provide a flatpak build. In the following I do try to compare the way a software developer can provide its software for various distributions. For that I will categorize linux distributions with the following type system which only takes the desktop in consideration:

@Ipar wrote:

@comzeradd wrote:

@gappleto97 wrote:

I have a strong preference against this. I don't want to have to install an entirely different distribution method just for one application.

You don't have to. It's just another option for people who want to.

I've no concerns regarding FlatPak being provided as well as Fedora RPMs, but I thought it was being suggested as an alternative to providing native distro packages for all the distros.

To support distributions like Fedora, Linux Mint >= 18.3, Endless OS I do see no need to provide extra native packages that are bound to the local environment (including dependencies). You don't have the need to install a distribution method for just one application, you do have it already on you're system. On Ubuntu that seems to be another story as long as flatpak.org recommends installing a ppa to install flatpak, I myself would consider that overkill. In short: I do see reason in both arguments without contradiction to the opening enhancement wish.

Post scriptum: While drafting this I send out a preliminary version. I want to apologise to everyone who did receive an additional mail due to my error.

[1] SELinux and Namespace Isolation is used and may be not provided by every distribution. [2] https://docs.snapcraft.io/core/install [3] https://www.flatpak.org/getting [4] https://insights.ubuntu.com/2016/06/24/howto-host-your-own-snap-store/

PorcelainMouse commented 6 years ago

I like the discussion here, but isn't this issue closed? I'm using Signal Desktop installed via flatpak now. (Thanks! I love it.) This enhancement request has been granted and achieved already.

exploide commented 6 years ago

I like the discussion here, but isn't this issue closed? I'm using Signal Desktop installed via flatpak now. (Thanks! I love it.) This enhancement request has been granted and achieved already.

The Signal release currently available via Flathub is not maintained by OpenWhisperSystems. There is no statement yet, if they encourage using this. In the past, OWS tended to prefer own distribution mechanisms. So this issue is probably waiting for OWS encouraging the Flathub release which they will continue to maintain or hosting their own Flatpak repository.

@scottnonnenberg said in another issue that they probably come up with rpm support first, then investigate distribution independent mechanisms later on. However, proposed rpm instructions were not implemented so far and Chrome Apps support is removed soon. :/ So likely I will switch to the Flathub version too, if this situation persists.

(btw, I'm wondering why offering distribution specific repositories and providing an independent mechanism is considered the way to go, as this increases the effort needed to release new versions)

bermeitinger-b commented 6 years ago

@dephekt

What happens right now if Flathub's repo or build tools are compromised? Is Flatpak downloading the .deb package to my PC from signal.org and building it all locally? Is Flatpak checking for a valid OWS GPG signature on the download before doing its work? I'm just trying to understand how the trust changes in this scheme without knowing a lot about how Flatpak handles this. I've been using the Flathub distribution for the last few weeks and I've been operating under the assumption that trust with OWS is broken this way; I'd just like to know if that's right or wrong in a (mathematically) provable way.

I'm currently updating flathub's repo with new versions when they appear. The only security in charge, currently that I know of, is a predefined SHA256 sum of the deb package on OWS's servers. It is build on flathub's build servers and then deployed once an official maintainer accepts the update. From my understanding there is no signature verification. The build bot downloads the deb file from the https-source, checks the SHA256 (at least I hope), extracts the files and creates a flatpak supported filesystem.

dephekt commented 6 years ago

@bermeitinger-b

It is build on flathub's build servers and then deployed once an official maintainer accepts the update. From my understanding there is no signature verification. The build bot downloads the deb file from the https-source, checks the SHA256 (at least I hope), extracts the files and creates a flatpak supported filesystem.

This is how I believe it to work as well. I doubt OWS would endorse such a solution based on past responses they have made, to wit it's my understanding that using Flathub would introduce security vulnerabilities where an end-user cannot be sure the package they just installed is honest and byte-for-byte what OWS signed on their offline build system, even if OWS is maintaining the Flathub source manifest. You would still need to trust Flathub's build system to be secure, which personally, I would not at the present time (and if I did trust it, I would still trust it less than OWS' build system).

If the build from Flathub was deterministic, then perhaps this would be OK, but if there's no logic somewhere to easily verify this during the installation, I would think that would not be a valid solution for the non-technical user. That is to say, if the user has to do a lot of work to confirm this themselves, it would not be reliable for the masses, in my opinion.

I believe Flatpak, in general, supports deterministic builds in that if you have the specific manifest and Flatpak SDK version it was built with and the input was deterministic, you should be able to get a deterministic output. [1] That being said, I have no idea how this works with Electron apps after reading this. It seems like it could be a lot of work and hacking to achieve deterministic builds of Signal Desktop through Flathub (possibly including changes to packages upstream from Flatpak), but I could be wrong.

bermeitinger-b commented 6 years ago

Pardon me for a probably naive question, but what's the advantage of building the Electron package (so running npm or yarn downloading roughly a million dependencies) instead of the current solution like downloading the already build deb file? I guess that it should be somehow possible to verify the state of the downloaded file with the public key from https://updates.signal.org/desktop/apt/keys.asc .

dephekt commented 6 years ago

@bermeitinger-b

what's the advantage of building the Electron package [...] instead of the current solution like downloading the already build deb file?

I don't think there's any advantage to building the Electron package; if anything, I would assume it to be less secure given all the moving parts involved. I didn't mean to imply that should be done.

I'm naive with Electron and Flatpak still too, so I'm trying to think through this logically: if Flathub was GPG verifying the (.deb) download they use to make the Flatpak build (which I think should be happening, if it isn't), the product you get from Flathub was still 'built' on a (presumably?) online system that isn't controlled or QA'd by OWS and isn't signed by OWS offline, so how can an end-user know what they got from Flathub is exactly what OWS intended them to have? What if various tools on Flathub were compromised at the time?

It seems to me that if OWS provided a signed Flatpak file themselves on signal.org that it would resolve the trust issues with the building of it, provided there's a built-in mechanism when installing a Flatpak file to verify the GPG signature for the end-user. I think expecting individual users to verify the signature themselves is too much to expect; I mean, me and you can do that and would have no problem with it, but not everyone will (my bet would be: most would not manually signature check) and at least with native package managers, that task is done for you and throws errors if signature validation fails.

Does that make sense? I'm still trying to wrap my head around this distribution method. Full disclosure: I don't have any dog in this fight and don't care how it's distributed, so long as what I ultimately get is the same thing Moxie securely signed offline. If that can't happen, then regardless of the distribution method, I would not be able to fully trust the app or recommend to someone else to use that distribution channel.

alatiera commented 6 years ago

@dephekt

I'm naive with Electron and Flatpak still too, so I'm trying to think through this logically: if Flathub was GPG verifying the (.deb) download they use to make the Flatpak build (which I think should be happening, if it isn't), the product you get from Flathub was still 'built' on a (presumably?) online system that isn't controlled or QA'd by OWS and isn't signed by OWS offline, so how can an end-user know what they got from Flathub is exactly what OWS intended them to have? What if various tools on Flathub were compromised at the time?

Flatpak builds are reproducible, so anyone could download the build manifest and build the exact same binary. The flathub builders also run without network access.

Alternative OWS could maintain it's own flatpak repository and distribute a flatpak bundle/*.flatpakref file that would also install the repo for the user. Flatpak builds can also be signed and verified with gpgkeys. The gpg key built-in the flatpakref files.

from the terminal it would look something like this: flatpak install --from https://foo.bar/whereflatpakis.flatpakref

or gnome-software would be one click that would do that automatically.

Here are the flatpak docs for distribution

alexlarsson commented 6 years ago

For the record, all flatpak repos (including flathub) is gpg signed by default (unless you explicitly disable it), in addition flathub is served over https.

bill-mcgonigle commented 6 years ago

I would prefer to have native repos (#1627 includes a build script to provide a signed RPM repo on OWS-owned infrastructure) but since that issue was closed, I would secondarily prefer to have an OWS-signed flatpack build from OWS servers. I personally don't care for third-party signing of builds; nothing against flathub, and I recognize that it's better than unsigned, but I think the authors should sign their builds.

All of the work done here is very much appreciated by me and if the flathub build manifest gets everything but the final GPG signing and hosting done, that's fantastic.

Currently the Signal Chrome App will lead a Fedora(/Qubes) user down a dead end on migration, so I hope a solution can be provided quickly (as well as for the other non- .deb distros).

bermeitinger-b commented 6 years ago

@alexlarsson

For the record, all flatpak repos (including flathub) is gpg signed by default (unless you explicitly disable it), in addition flathub is served over https.

I appreciate that, but still, flathub's build server is building the package and signing it with their key. Users here would prefer it to be signed by OWS directly. Just because a package is signed, doesn't mean that it's safe to install.

During the flathub's build, there might be an option to check the deb file's signature against the OWS key.

alexlarsson commented 6 years ago

There is currently no ability to supply a key to verify the deb. However, the size and sha256 of the deb is supplied in the (signed) flatpak wrapper, so if the packager verified the deb locally and then calculated the sha256, it seems to be of similar strength.

ykne commented 6 years ago

Which document outlines creating local signal flatpak file? I can only see official instructions for .deb in CONTRIBUTING.md and unofficial for .rpm in #1627 .

exploide commented 6 years ago

No document in this repository, since the flatpak is unofficial, yet. You can install it directly from Flathub, see https://flathub.org/

If you want to build it by your own, you can find the metadata files for Signal in this repository: https://github.com/flathub/org.signal.Signal You would need to learn how to build flatpaks locally, e.g. from http://docs.flatpak.org/en/latest/ But if you do this, you maybe also need to build the Electron Base App and the Freedesktop runtime by yourself, if you don't trust them.

dephekt commented 6 years ago

@alexlarsson Verifying the checksum only provides validation of the file integrity. If an adversary has access to modify the package prior to delivery, modifying the checksum one uses to verify against would likely not take significantly more effort.

With an OpenPGP signature, one would get end-to-end, verifiable integrity and authenticity. Presuming the private key used by the original author is adequately protected and the OpenPGP check is happening automatically by the package manager of the end-user, it would be significantly more difficult for an adversary to introduce a malicious package without detection.

jkterry1 commented 6 years ago

Anything news here?

gasi-signal commented 6 years ago

@justinkterry Realistically, with limited resources—two people full-time on desktop app—there are other features that have higher priority and officially supporting more platforms might also introduce extra support needs which we might not be able to meet to people’s satisfaction with the current team size.

We’d appreciate community help on improving the documentation on how to install the app from source for people on non-Debian systems in the meantime. Hopefully, as we grow our team, we can make the app more easily available on more platforms.

jkterry1 commented 6 years ago

Alright; thanks a ton for your transparency, I genuinely appreciate it.

The one thing I'll add, since this thread has been sort of merged with the rpm thread, is that at minimum getting a release for rpm systems should be a priority based on market share in Linux. Virtually all mature Linux software fully supports both, but official support beyond those two is uncommon for major user facing software due to market share and ease of development reasons. Examples include Steam, Maya and Google Chrome (not Chromium). Stopping at releasing rpm and deb, depending on the goals of the project, could be considered a perfectly reasonable.

I mention this at all because I want to switch my laptop from a .deb to a .rpm distro and this is the only piece of software I use that doesn't natively support .rpm.

On Fri, Apr 6, 2018 at 11:43 AM Daniel Gasienica notifications@github.com wrote:

@justinkterry https://github.com/justinkterry Realistically, with limited resources—two people full-time on desktop app—there are other features that have higher priority and officially supporting more platforms might also introduce extra support needs which we might not be able to meet to people’s satisfaction with the current team size.

We’d appreciate community help on improving the documentation on how to install the app from source for people on non-Debian systems in the meantime. Hopefully, as we grow our team, we can make the app more easily available on more platforms.

— You are receiving this because you were mentioned.

Reply to this email directly, view it on GitHub https://github.com/signalapp/Signal-Desktop/issues/1639#issuecomment-379293531, or mute the thread https://github.com/notifications/unsubscribe-auth/AShd7IN1QHozGboLEV56Vi_3EkAV5FP5ks5tl40cgaJpZM4QN3sw .

-- Thank you for your time, Justin Terry

ykne commented 6 years ago

@justinkterry if you just want rpm - do this

rm -rf Signal-Desktop
git clone https://github.com/WhisperSystems/Signal-Desktop.git
cd Signal-Desktop/
git checkout tags/$(git tag -l | grep -v beta | tail -1)
sed -i -e 's/^const usingTrayIcon = startInTray.*/const usingTrayIcon = true;/' main.js 
npm install && npm run generate && SIGNAL_ENV=production npm run build -- --linux rpm
sudo dnf install ./dist/signal-desktop-*.x86_64.rpm

this method has been reported long time ago and I am really puzzled why rpm is still not officially released. sed line is my personal preference to always use system tray. there is absolutely no reason to require an argument to enable system tray.

ykne commented 6 years ago

@justinkterry you can also try https://copr.fedorainfracloud.org/coprs/luminoso/Signal-Desktop/

ghost commented 6 years ago

@gasi-signal Why not, for the moment, just add officially ykne's solution in the "how to install signal" page https://support.signal.org/hc/en-us/articles/214507138-How-do-I-install-Signal-Desktop- and "download page" https://signal.org/download/ ?

brian-provenzano commented 6 years ago

@ykne - thanks for posting this. It works great. The only thing I'd add is that you do need "npm" and "rpm-build" pkg installed

Also, I agree - I'm not sure why there isnt an official rpm build based on how simple it is...

ykne commented 6 years ago

I looked at luminoso rpm build spec and came up with

rm -rf Signal-Desktop
git clone https://github.com/WhisperSystems/Signal-Desktop.git
cd Signal-Desktop/
git checkout tags/$(git tag -l --sort=v:refname | grep -v beta | tail -1)
yarn install
yarn generate --force
SIGNAL_ENV=production npm run build -- --linux rpm
sudo dnf install ./dist/signal-desktop-*.x86_64.rpm

yarn is installed from https://dl.yarnpkg.com/rpm/ main.js changed, will deal with tray icon later.

G-Ray commented 6 years ago

Signal is already distributed on https://flathub.org, So I think we can close this issue :)

brian-provenzano commented 6 years ago

Signal is already distributed on https://flathub.org, So I think we can close this issue :)

Is this flatpak officially built and supported by Signal or is it a third party build? Seems like if it was it would be on the official download page on the signal desktop website? For a security app I'd only trust the build if it was done by Open Whisper /Signal. Can anyone confirm?

bermeitinger-b commented 6 years ago

It is not built officially by Open Whisper Systems but by Flathub. You can see the repository here https://github.com/flathub/org.signal.Signal

johannes87 commented 6 years ago

The file https://github.com/flathub/org.signal.Signal/blob/master/org.signal.Signal.json lists https://updates.signal.org/desktop/apt/pool/main/s/signal-desktop/signal-desktop_1.16.2_amd64.deb, so it's directly from signal.org.

jplatte commented 6 years ago

@johannes87 that doesn't mean that that file is maintained by Open Whisper Systems, or that the flatpak packages are built by them. It only means that the current version of that build script creates the flatpak package from the deb package at updates.signal.org, which could still be the case if it was a build script for a malicious redistribution (e.g. one that includes a keylogger).

brian-provenzano commented 6 years ago

Yeah - we need an official build flatpak. Especially since this is a security product

heyakyra commented 4 years ago

Fedora users stuck on the Chrome extension for Signal now get a warning that they need to download the desktop client for Linux, but there is no download available for Fedora. No official flatpak or #1630 RPM

rmader commented 4 years ago

Fedora users stuck on the Chrome extension for Signal now get a warning that they need to download the desktop client for Linux, but there is no download available for Fedora. No flatpak or #1630 RPM

The signal app is already present on flathub (https://flathub.org/apps/details/org.signal.Signal). The default flatpak repo in fedora only has very few apps so far, so most fedora users should enable the flathub repo (https://flatpak.org/setup/Fedora/)

Edit: this is of course not sufficient for people requiring a official OWS version, sorry for the noise.

heyakyra commented 4 years ago

Isn't the Flatpak unofficial? That's dangerous for software specifically for encryption, not to mention Signal developers have made it clear that a priority is discouraging unofficial distributions that may contain or introduce backdoors.

yithian commented 4 years ago

The flathub build does not appear to be official - it's not mentioned on https://www.signal.org/download/ and https://github.com/signalapp/Signal-Desktop/issues/1639#issuecomment-343240526 suggests that the flathub package is not owned or maintained by OWS.