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

[Antoine Beaupre]

On Sat, Mar 30, 2019 at 07:14:38PM +0100, intrigeri at debian.org wrote:
> 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:

[...all valid reasons elided...]

So what will be the way forward for Debian users in buster? What does
Tails do with this?

TL;DR: TBL in backports or install by hand from TPO, AFAIK.

I am still using torbrowser-launcher (TBL) because it hooks the Tor
chain of trust into the Debian chain of trust. In other words, I don't
have to "blindly curl | bash" from torproject.org (TPO).

I know TBL is pretty much an *equivalent* to curl | bash because it
downloads arbitrary, unaudited (from Debian's perspective) code from
TPO, but at least it hooks into the cryptographic signatures.

I also know that I can go on torproject.org, download the Tor Browser
Bundle (TBB), check the signature by hand, and then rely on the TBB
self-update mechanisms for future updates. But that seems like
low-level gymnastics I wouldn't expect a normal user to be even
*capable* of doing safely. I'm pretty sure *I* could nail it, but being
a sysadmin shouldn't be a requirement to installing TBB on Debian. :)

So I see a few long-term solutions to the "how to install TBB in Debian"
problem in Buster:

 1. maintain through backports (seems to have been the option taken for
    stretch)

 2. drop TBL and rewrite it as a one-shot installer, like we had for
    Flash, mstt-corefonts and still have (I suspect?) for other packages

 3. drop TBL and instead ship a torproject-archive-keyring package which
    will add the upstream TBB sources.list and trust anchors to install
    TBB, as per https://wiki.debian.org/DebianRepository/UseThirdParty

 4. drop TBL and shipp TBB directly in Debian

Option 1 seems to be the status quo that's implied in this bug report,
and it somewhat works except people can't actually test that in buster
right now, unless they deploy a sid sources.list. TBL also has all sorts
of other problems with locale and other issues that keep on coming up so
I wonder if we really want to maintain this for another decade...

Option 2 might mean more work and upset upstream TBL, but it "feels"
more in line with how we did things traditionnally... It's a significant
departure from the current approach however, so I'm not sure it's the
best approach, especially since we don't (as far as I know) have good
mechanisms to implement this that could serve as a template here.
msttcorefonts and flash were all built by hand, IIRC.

Option 3 gets into the real "doing things right" territory, in my
opinion, and would be an option I would favor in the short term. It's
obviously too late to get that in buster, but would at least solve the
immediate "trust path" problem. Unfortunately, I just realized that
upstream doesn't actually have a .deb at all, so this wouldn't work
anyways. ;) (deb.tpo is only for the tor daemon, not TBB.)

Option 4, therefore, would require more ambitious packaging work. Maybe
we could talk with upstream to see if that would be possible? There are
Debian packages for Firefox, after all - how hard could it possibly be
to do the same for TBB? ;)

Anyways, I would be glad to hear what the options are here and if this
inventory is complete!

Thanks,

A.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://alioth-lists.debian.net/pipermail/pkg-privacy-maintainers/attachments/20190503/9320efc6/attachment.sig>