Best way to install Signal on Fedora?

It seems like there are two decent community built options:

https://software.opensuse.org/download.html?project=network:im:signal&package=signal-desktop

And

I’ve been using the flatpak so far, but according to discussions I’ve found about the rpm package, “it builds signal and its dependencies offline and without pre-built binaries shipped along with the repo” (Packages for rpm-based linux distributions · Issue #1630 · signalapp/Signal-Desktop · GitHub) which sounds very good for security. Any thoughts?

Just stick with flatpak and its sandbox

1 Like

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.

2 Likes

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 :man_facepalming:. 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)

Now that’s a smart way to do something. Haven’t tried distrobox yet. One day, one day.

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?

1 Like

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.

Yeah it’s the convenience aspect and also relying on the user to check for and install updates manually is not ideal for security

1 Like

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.


Edit:

Done. I am not sure if I’m allowed to post my own blog here, but here’s the post I made walking through the manifest: Signal Flatpak Manifest Review | Brain Overflow

I assume I’ll be told if it’s not allowed :slight_smile:

2 Likes

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

2 Likes

This is true, i didn’t really mean to imply it’s totally unwarranted, if that’s what ‘FUD’ usually implies then my bad.

I’ll check out Proton’s manifest, no promises that it’s not beyond me though haha.

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.

3 Likes

Good points. A way to get notified of manifest changes could be to star the repo for the manifest, but obviously that requires an account, etc.

2 Likes