Opened 2 years ago

Last modified 11 months ago

#25578 new enhancement

Package and distribute Tor Browser using Flatpak

Reported by: mjog Owned by: tbb-team
Priority: Medium Milestone:
Component: Applications/Tor Browser Version:
Severity: Normal Keywords:
Cc: intrigeri, anarcat Actual Points:
Parent ID: Points:
Reviewer: Sponsor:


Please provide a Tor Browser package for Flatpak, and ideally publish it on Flathub. Aside from getting the added security benefit of the Flatpak sandbox, this will make it possible for normal people to install Tor Browser on Linux - the current binary tarball isn't great.

Child Tickets

Change History (11)

comment:1 Changed 2 years ago by gk

That's nothing we will spend time on in the foreseeable future. But if someone wants to try this out, feel free.

comment:2 Changed 22 months ago by rugk

I'd also +1 this here. As the OP mentioned the added sandbox/isolation won't hurt and you can easily distribute it yourself, too. It does not have to be on Flathub.

And Firefox itself is possible to run in flatpak, already. E.g. in there was some stuff, but it seems to be outdated. has some working Firefox packages. Since Firefox 62 it can also read files from other dirs than "~/Downloads" properly, see Thus it also does not need "host" permission or so, so files in the user's dir are protected.

comment:3 Changed 22 months ago by gk

That reminds me of which is talking about Flatpak security.

comment:4 Changed 22 months ago by mjog


Tin-foil-hat drivel by the same kinds of people that dislike systemd because they can't imagine that a better way of doing something that isn't the way they've always done it.


comment:5 Changed 22 months ago by yawning

This really sucks to do because of the sub-optimal way that the various Tor components are integrated into Tor Browser. The flatpak model does not mesh well with Tor Browser currently shipping a user profile directory that is expected to be volatile.

There are various kludges that can be done to work around this, but more realistically the better solution is to solve #10760 among other things.

The protections provided by the sandbox would still be severely lacking because you would want to decouple the tor process and the firefox one, but at least it may improve the distribution situation.

comment:6 Changed 16 months ago by intrigeri

Cc: intrigeri added

comment:7 Changed 16 months ago by anarcat

Cc: anarcat added

available for testing.

comment:8 Changed 13 months ago by muelli

The following manifest seems to work for me:

app-id: org.torproject.browser

runtime: org.gnome.Platform
runtime-version: "3.32"
sdk: org.gnome.Sdk


  - --socket=x11
  # - --share=ipc
  - --share=network

  - name: torbrowser
    buildsystem: simple
        - install -D Browser/browser/chrome/icons/default/default64.png   /app/share/icons/hicolor/64x64/apps/org.torproject.browser.png
        #- install -D Browser/start-tor-browser.desktop /app/share/applications/org.torproject.browser.desktop
        - sed -i s,Icon=torbrowser,Icon=org.torproject.browser,  torbrowser.desktop
        - sed -i "s,Exec=torbrowser-launcher %u,Exec=/app/bin/,"  torbrowser.desktop
        - install -D torbrowser.appdata.xml  /app/share/metainfo/org.torproject.browser.appdata.xml
        - install -D torbrowser.desktop  /app/share/applications/org.torproject.browser.desktop
        - mv Browser /app
        - install -D -m a=rx   /app/bin/
      - /Browser/TorBrowser/Docs/
        - type: file
          sha256: 4aa47248ce6ea3b54fe349bfa03169dc72cceb2f206d517cbf37eeab929d68d0

        - type: file
          sha256: edc4a08adcfb78468a34bd46ef8f0de0ef5fdb141bd438709e755dc8b2a3eee6

        - type: script
            # Yes. This is dirty. The tarball contains a Firefox profile directory which Firefox expects to be able to write...
            # The tmp directory is, at least when following this manifest and not overwriting the settings, a tmpfs, so we can (or have to) copy over everytime we launch.
            - cp -ar --reflink=auto /app/Browser /tmp/
            - cd /tmp/
            - cd Browser
            - ./start-tor-browser

        - type: archive
          sha256: 4f2011f83f014abddc1a23ead058efd7b8ec75bfdd23040573b4c6c3be02b496

I build with flatpak-builder --user --install --ccache --keep-build-dirs --force-clean -v --repo=/var/tmp/fb.repo fpbuilder org.torproject.browser.yml.
I'd love to build from source, but I haven't had much success with that in the past.

is anyone from upstream interested in co-maintaining the package on Flathub if it gets accepted?

comment:9 Changed 13 months ago by rugk

Oh, did not get any progress on this one. Great to see people are working on it! (or actually you, @muelli)

In the meantime I've also asked for this on:

It would be glad to see it on Flathub or similar!

comment:10 Changed 12 months ago by rugk

@muelli maybe you should just follow these instructions?

comment:11 Changed 11 months ago by intrigeri

Meanwhile, there's a PR for adding torbrowser-launcher to flathub:

Its main advantages I can perceive over muelli's version are:

  • It does need to be updated every time there's a Tor Browser release. Rebuttal: torbrowser-launcher is regularly outdated e.g. wrt. upstream signing keys, TLS certificates (that it used to pin at some point, did not check recently), upstream URLs, etc.; so yeah, this solves the Tor Browser distribution problem on Linux most of the time, except when these users face a scary message telling them that some signature could not be verified or something, and they don't get a working Tor Browser. To deal with that, I believe that the maintainers of a Flatpak based on torbrowser-launcher will inevitably end up maintaining a series of patches on top of it, that they have to update in a hurry (+ upload a new Flatpak) every time the current release of torbrowser-launcher is unable to install Tor Browser. I'm not sure that's better than having to change the URL + hashes in the Flatpak definition and then upload it on every Tor Browser release.
  • torbrowser-launcher downloads a localized Tor Browser tarball, while muelli's only supports en-US at the moment.

Its main drawbacks compared to muelli's approach are:

  • It needs all the torbrowser-launcher dependencies, starting with the org.kde.Platform + org.kde.Platform.Locale runtimes (765MB to download). I guess it's only a drawback for GNOME persons like me, and for Linux distros that default to GNOME or don't support anything else, such as Ubuntu, Tails, Fedora, etc.
  • Once you've installed the Flatpak, on first launch it downloads Tor Browser itself, which will then feel tiny in comparison, but is still far from ideal UX, and probably does not meet users' expectations as in: "I've just downloaded and installed an app and when I start it, I expect to see the app, not a dialog that tells me it's now downloading the app".

I've not checked how either Flatpak deals with upgrades. IIRC torbrowser-launcher dropped support for upgrading Tor Browser itself, in favor of letting Tor Browser handle it like everywhere else (except Tails and other weirdos, but well, you know :)

@muelli: it's a bit early for me to commit to anything on this front, but I'm definitely interested and keeping an eye on those things, primarily because 1. I'd like all Linux users to have a nice way to install Tor Browser; 2. at some point, Tails may want/need some way to upgrade Tor Browser without putting out a full blown Tails release, and Flatpak is one of the options on the table. And if you're the person I guessed you are: loved your GUADEC talk, as usual :)

Note: See TracTickets for help on using tickets.