Though flatpaks are available for signal , you can also install Signal in a distrobox running Debian or ubuntu distro for which signal has an official repos . In this way you can also add the beta repo for running the beta versions of the app.
Also, it doesn’t seem that Flatpak package is official, so if you are uncomfortable using an unofficial port of the official Signal client, then please don’t use the Flatpak version. If, on the other hand, you trust the community to maintain the app, then go ahead, use it.
Edit : Eh, I should read your post before writing . Well, then yes to everything @pika said.
* and/OR trust yourself to read and vet the manifest. (Flatpaks have manifests, which are somewhat similar to how AUR packages have pkgbuild files, which allow you to see how the package is built, and from what sources. So experienced users can establish trust in an unofficial flatpak without necessarily trusting the person who published it).
I think my preference would be the distrobox + the official debian package. But I think the flatpak is most likely safe and not too hard to vet yourself. And I’m still holding out hope that Signal will take over the unofficial flatpak at some point (from what I stand it seems like a no brainer considering it would work across (almost) all distros, but I think they have expressed disinterest in doing so)
Sometimes I think people should be reminded that you can compile signal into an AppImage or .rpm file…
Is compiling from source less advocated these days? I mean sure it takes more than 5 mins of compile time and you need to install additional dependencies one time beforehand, but is that really an issue?
Or is it more like the binary that it produces is not reproducible and thus uncomfortable to use despite compiling it yourself?
its not about advocating it or not . An ordinary user should be able to use whichever way they seem is best and easiest for them. If a user choses not to go to the terminal and run a bunch of commands then so be there decision.
There’s a lot of fud about this flatpak. It’s probably the best/easiest way to use Signal desktop and keep it updated easily. I think I’m going to review the manifest and make a post about it.
I don’t think it is quite fair to call concerns/caution about an unverified 3rd party build of an important private messenger to be FUD. This is exactly the type of situation where people should approach with caution and skepticism.
However, flatpaks can be vetted individually, so we can establish some trust in a flatpak on our own if we are able to properly interpret the manifest file and confident in our ability to do so. Fortunately, in the case of the Signal Flatpak, the manifest is quite straightforward compared to some others (ProtonVPN for example)
Signal Flatpak Manifest
id: org.signal.Signal
base: org.electronjs.Electron2.BaseApp
base-version: '23.08'
runtime: org.freedesktop.Platform
runtime-version: '23.08'
sdk: org.freedesktop.Sdk
command: signal-desktop
separate-locales: false
finish-args:
# X11 performance
- --share=ipc
# We need X11
- --socket=x11
# Access to wayland
- --socket=wayland
# Audio Access
- --socket=pulseaudio
# All devices (camera, microphone for calls)
- --device=all
# Network Access
- --share=network
# We need to be able to inhibit sleep
- --system-talk-name=org.freedesktop.login1
- --talk-name=org.gnome.SessionManager
- --talk-name=org.freedesktop.PowerManagement
- --talk-name=org.freedesktop.ScreenSaver
# These are for notifications/tray icons
- --talk-name=org.gnome.Mutter.IdleMonitor
- --talk-name=org.kde.StatusNotifierWatcher
- --talk-name=com.canonical.AppMenu.Registrar
- --talk-name=com.canonical.indicator.application
- --talk-name=org.ayatana.indicator.application
# Environment Variables to control the behavior
- --env=SIGNAL_USE_TRAY_ICON=0
- --env=SIGNAL_START_IN_TRAY=0
- --env=SIGNAL_USE_WAYLAND=0
- --env=SIGNAL_DISABLE_GPU=0
- --env=SIGNAL_DISABLE_GPU_SANDBOX=0
# Use same mouse cursors as host
- --env=XCURSOR_PATH=/run/host/user-share/icons:/run/host/share/icons
modules:
- name: signal-desktop
buildsystem: simple
build-commands:
- |
bsdtar -Oxf signal-desktop.deb 'data.tar.xz' |
bsdtar -xf - \
--exclude='./usr/share/doc'
- |
if [ -d "opt/Signal" ]; then
mv "opt/Signal" "${FLATPAK_DEST}/Signal"
BETA_SUFFIX=""
elif [ -d "opt/Signal Beta" ]; then
mv "opt/Signal Beta" "${FLATPAK_DEST}/Signal"
ln -s "${FLATPAK_DEST}/Signal/signal-desktop-beta" "${FLATPAK_DEST}/Signal/signal-desktop"
BETA_SUFFIX="-beta"
else
exit 1
fi
install -Dm0644 "usr/share/applications/signal-desktop${BETA_SUFFIX}.desktop" "${FLATPAK_DEST}/share/applications/${FLATPAK_ID}.desktop"
for size in 16 24 32 48 64 128 256 512; do
install -Dm0644 "usr/share/icons/hicolor/${size}x${size}/apps/signal-desktop${BETA_SUFFIX}.png" "${FLATPAK_DEST}/share/icons/hicolor/${size}x${size}/apps/${FLATPAK_ID}.png"
done
- install -Dm0755 signal-desktop.sh "${FLATPAK_DEST}/bin/signal-desktop"
- install -Dm0644 "${FLATPAK_ID}.metainfo.xml" "${FLATPAK_DEST}/share/metainfo/${FLATPAK_ID}.metainfo.xml"
- desktop-file-edit --set-key=Exec --set-value='signal-desktop %U' "${FLATPAK_DEST}/share/applications/${FLATPAK_ID}.desktop"
- desktop-file-edit --set-key=Icon --set-value="${FLATPAK_ID}" "${FLATPAK_DEST}/share/applications/${FLATPAK_ID}.desktop"
sources:
- type: file
dest-filename: signal-desktop.deb
url: https://updates.signal.org/desktop/apt/pool/s/signal-desktop/signal-desktop_7.9.0_amd64.deb
sha256: 22fd961b592f077b44885bb83b2d29a342a5a560b07da94334e5ecb4efc2f9ed
x-checker-data:
type: debian-repo
package-name: signal-desktop
root: https://updates.signal.org/desktop/apt
dist: xenial
component: main
only-arches:
- x86_64
- type: file
path: signal-desktop.sh
- type: file
path: org.signal.Signal.metainfo.xml
Personally I feel confident enough in my ability to interpret Signal Flatpak’s manifest to have moderate trust in it (at least trust that it isn’t intentionally malicious). But I do not believe I can adequately vet more complex flatpaks.
I started writing this before your edit, everything above came before the edit. Looks like we are more or less on the same page. Thanks for the blogpost and the comments.
If you feel confident in your understanding, I’d love to see you take a stab at a more complex manifest like Proton’s
For me, the issue is not about whether the Flatpak manifest is trustworthy or not now, but whether it will continue to be. The Verified status is a good guarantee that the developer will not later ship a bad update; for example, by injecting a bad dependency. (I say this as someone who maintains an unverified Flatpak myself). Fortunately, the Signal manifest is probably one of the simplest that exists. Part of that is because it’s based on the .deb.
I like that AUR helpers, for example, provide diffs for you to look through when the PKGBUILD is updated. You get notified when permissions change with the Flatpak package, but not when the manifest has an updated/new dependency.
Flathub has manual reviews for submissions and manual reviews for when manifests ask for more permissions, but I don’t know if anything else triggers it.
Though it should be noted that Verified can just mean someone else has been given the developer’s blessing to maintain the package.
Otherwise, toolbox or distrobox are great easy ways of installing Signal and keeping it up-to-date.
Voice messages not working is probably caused by a flatpak permissions issue. If the signal flatpak cannot access Pulse-audio/Pipewire it will not be able to playback audio.
. Well, then yes to everything 