Title.
I use Fedora and would love to have Signal on desktop but Signal themselves don’t officially support Fedora and its derivatives - hence the question.
Please clarify. Thanks!
1 Like
You can compile the binaries yourself but that also has other problems.
IIRC PG specifically does not endorse the usage of the desktop client of Signal.
In the yaml file from the flathub github I see that it uses from the .deb file from the Signal website.
I can’t speak to whether this is sufficient, just bringing it up for discussion purposes.
1 Like
I’d hope it’s monitored by the community but as far as I can tell, there’s no hard safety mechanisms in place. By using it, you’d just be hoping that (if it isn’t gonna be you) someone is checking to see that it’s legit. Maybe a Debian Distrobox container could be a solution?
2 Likes
the Signal flatpak uses insecure Electron, so secureblue and GrapheneOS recommend just using Signal on mobile.
They’re not meant for security, but for intergration
I never realized that Signal maintains a .deb, I wouldn’t expect a security focused messenger to provide options for Debian rather than Fedora.
Is a .deb easier to make than an RPM?
Yes, it was already mentioned that Privacy Guides recommends you avoid linking your device to your desktop for optimal security. But that’s a major inconvenience to most people, hence why Signal desktop exists in the first place.
The nature of the question is about whether we could trust the Flathub community build of Signal, which I suggested is an issue you might avoid by using the official Signal application in a Debian Distrobox container if you’re using an unsupported host OS such as Fedora. Neither the question nor my solution had anything to do with trying to sandbox Signal.
1 Like
And it wasn’t already mentioned that the Signal flatpak uses Electron, so Signal desktop use is especially insecure.
The original post asked about a “safe and secure” way to use Signal on desktop, so I mentioned a security flaw of your suggestion.
This is something you can and should determine for yourself, and is good to learn if you will use unofficial flatpaks. Flatpaks have a manifest that shows you how it is built and the source it is built from (Flathub always includes links to the manifest).
I personally do have moderate trust in the unofficial Signal Flatpak. In part because I have reviewed the manifest to the best of my (limited) ability. And cross-referenced my own basic analysis, with that of others who had the same concern and bothered to look, as well as relevant statements from the person responsible for the unofficial flatpak:
#300 (2022)
What is your attack scenario? You can only be safe against something.
We had a similar discussing already in #171 about the update process.
If you want a trust scale, then no, this repackaging requires more trust of the user than the deb file.
- Anyone with master access/maintainer status can arbitrarily change any file in the repo, e.g. replace the url of the deb to a malicious one. (Well, or GitHub could probably modify any file, it’s their servers.)
- The server that builds the flatpak is run by Flathub. It downloads the build script, runs the commands (meaning downloading the deb file), extracting it, and copying things around. A rogue build server could arbitrarily modify any file.
For the first one, you could check the commits, especially if the URL to the deb points to the correct location.
The second one can be circumvented by building the flatpak yourself with flatpak-builder, so you are removing flathub from the equation. (However, it will still download the build/runtime requirements from flathub.)If you don’t trust flatpak itself, you could build it yourself using the arch’s PKGBUILD.
#171 (2021)
I understand and support your issue regarding the security of the flatpak builds. You mostly answered your question with
But Signal doesn’t care about Flatpak and only supports a .deb file for Debian/Ubuntu…
This is the reason (among sandboxing and runtime requirements) for the existence of this flatpak repo. If there would be none, there is no (easy) possibility to install Signal Desktop on non-apt distributions.
The update process is now done with a bot which scans for new versions directly from the Signal’s apt-repo and then creates a Merge Request with the new version. The “only” verification is the SHA256 sum, you are correct. If you find a way to verify the binary with Signal’s key, you’re open to work on it and we’ll happily accept the added security. A problem here is that the deb file itself is not signed and there is no specific signature file on the server. Also, flatpak does not support GPG verification the same way as hash verification, so we would have to implement it manually.
The
signal.shfile is needed for launching Signal Desktop because it is an Electron application which needs thezygote-wrapper.If you follow the discussion about the RPM distribution, you can see that their main argument is that they do not have the time/money/personnel to maintain different packaging formats. If they add flatpak, the next person comes with snap support, then AppImage, and so on.
There might be ways to attack this application by attacking any of the intermediate layers (Flatpak, Electron, node, etc.), the apt-repository, the Flathub repository, this repository, Flathub’s build server, and also any npm dependency, and many more.
This Flatpak is not endorsed or in any kind supported by anyone from Signal.
Trustworthiness of non-official Flatpak packages · Issue #171 · flathub/org.signal.Signal · GitHub
One thing I like about the publishers comments, is that they are really not trying to convince anyone they shoudld be trusted or covering up the additional risk that using the unofficial flatpak brings with it. And are also advising other ways, to avoid additional trust (building it yourself)
The other way that has not been mentioned is toolbox/distrobox to install Signal’s official debian version on non-debian distros. There are a few other creative solutions as well.
5 Likes
Thank you so much for the detailed answer.