Package and distribute Tor Browser using Flatpak

added component::applications/tor browser owner::tbb-team priority::medium reporter::mjog severity::normal status::new type::enhancement labels

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

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 https://gitlab.gnome.org/gbraad/flatpak-firefox there was some stuff, but it seems to be outdated. https://firefox-flatpak.mojefedora.cz/ has some working Firefox packages. Since Firefox 62 it can also read files from other dirs than "~/Downloads" properly, see https://bugzilla.mozilla.org/show_bug.cgi?id=1490186. Thus it also does not need "host" permission or so, so files in the user's dir are protected.

Trac:
Username: rugk

That reminds me of https://flatkill.org/ which is talking about Flatpak security.

flatkill

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.

Rejoiner: http://ramcq.net/2018/10/15/flatpak-sandbox-security/

Trac:
Username: mjog

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 (moved) 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.

Trac:
Cc: N/A to intrigeri

available for testing.

Trac:
Cc: intrigeri to intrigeri, anarcat

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

command: launch.sh

finish-args:
  - --socket=x11
  # - --share=ipc
  - --share=network

modules:
  - name: torbrowser
    buildsystem: simple
    build-commands:
        - 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/launch.sh,"  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 launch.sh   /app/bin/launch.sh
    
    cleanup:
      - /Browser/TorBrowser/Docs/
    sources:
        - type: file
          url: https://raw.githubusercontent.com/micahflee/torbrowser-launcher/develop/share/metainfo/torbrowser.appdata.xml
          sha256: 4aa47248ce6ea3b54fe349bfa03169dc72cceb2f206d517cbf37eeab929d68d0

        - type: file
          url: https://raw.githubusercontent.com/micahflee/torbrowser-launcher/develop/share/applications/torbrowser.desktop
          sha256: edc4a08adcfb78468a34bd46ef8f0de0ef5fdb141bd438709e755dc8b2a3eee6

        - type: script
          commands:
            # 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
          dest-filename: launch.sh

        - type: archive
          url: https://www.torproject.org/dist/torbrowser/8.5.3/tor-browser-linux64-8.5.3_en-US.tar.xz
          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?

Trac:
Username: muelli

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:

torbrowser-launcher: https://github.com/micahflee/torbrowser-launcher/issues/407
Fedora torbrowser-launcher package: https://bugzilla.redhat.com/show_bug.cgi?id=1731284
and started a general discussion for my use case in the Fedora forums: https://discussion.fedoraproject.org/t/tor-browser-on-silverblue/2032?u=rugk

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

Trac:
Username: rugk

@muelli maybe you should just follow these instructions? https://github.com/flathub/flathub/wiki/App-Submission#how-to-submit-an-app

Trac:
Username: rugk

Meanwhile, there's a PR for adding torbrowser-launcher to flathub: https://github.com/flathub/flathub/pull/1135.

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

moved to tpo/applications/tor-browser#25578 (moved)

Package and distribute Tor Browser using Flatpak

Child items ...

Activity