[Pkg-privacy-maintainers] Bug#926042: torbrowser-launcher should not be included in Buster

[intrigeri at debian.org]

Source: torbrowser-launcher
Version: 0.3.1-2
Severity: serious

Hi,

for basically the same reasons that made us not include
torbrowser-launcher in Stretch, IMO it should not be part of Buster
either:

1. This downloader package requires updates, from time to time, to
   cope with changes in how Tor Browser is distributed upstream
   (OpenPGP keys, URLs, SSL certificates, you name it).

2. One of the key bonuses brought by torbrowser-launcher, compared to
   installing Tor Browser as recommended by the Tor project, is that
   it ships AppArmor profiles. Debian Buster will ship with AppArmor
   enabled by default, so keeping these profiles in a shape that does
   not break Tor Browser will soon become a critical requirement.

   These profiles are currently in a poor shape. For example, Tor
   Browser runs under the wrong profile when it restarts after
   applying an upgrade, which breaks all kinds of functionality.

   These profiles need regular updates; whenever a new Tor Browser
   that requires such updates is needed, Debian stable users would
   have a broken Tor Browser until someone (generally me so far) have
   time to prepare such updates and submit them upstream, then someone
   on the pkg-privacy team includes them in an upload to sid, and
   finally backport them into some kind of stable update (presumably
   buster-updates, as waiting for the next Buster point-release can
   take up to 4 more months of breakage). I personally cannot commit
   to do my part of the work in a timely manner for the entire Buster
   lifetime; and I have doubt pkg-privacy can reasonably commit to do
   the rest of the work in a timely manner either.

3. torbrowser-launcher upstream maintains no LTS branch so fixing any
   problem of one of the aforementioned kinds in Debian stable would
   require us to backport the fix, somehow (and occasionally to
   prepare the fix ourselves, in case upstream is not reactive
   enough). I'm sure that this should be straightforward in many
   cases, but:

    - It seems to me that during the Buster development cycle, we
      lacked the time+energy to backport such fixes to sid
      consistently. Adding another target for backports seems
      unreasonable to me.

    - Major technology changes upstream can make such backports much
      harder. For example, torbrowser-launcher 0.3.0 switched from
      python2 to python3, from gtk2 to Qt5, and from twisted to
      requests/socks.

If my team-mates disagree and want to give it a try anyway, fine.
Then, I would strongly recommend disabling the AppArmor profiles in
Buster by default.

Cheers!
-- 
intrigeri