Debian Bug report logs - #926042
torbrowser-launcher should not be included in Buster

Reply or subscribe to this bug.

Display info messages

Message #5 received at submit@bugs.debian.org (full text, mbox, reply):

From: intrigeri@debian.org

To: Debian Bug Tracking System <submit@bugs.debian.org>

Subject: torbrowser-launcher should not be included in Buster

Date: Sat, 30 Mar 2019 19:14:38 +0100

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

Message #10 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupre <anarcat@debian.org>

To: intrigeri@debian.org

Cc: 926042@bugs.debian.org

Subject: Re: Bug#926042: torbrowser-launcher should not be included in Buster

Date: Fri, 3 May 2019 09:53:53 -0400

[Message part 1 (text/plain, inline)]

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

[signature.asc (application/pgp-signature, inline)]

Message #15 received at 926042@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Antoine Beaupre <anarcat@debian.org>

Cc: 926042@bugs.debian.org

Subject: Re: Bug#926042: torbrowser-launcher should not be included in Buster

Date: Fri, 03 May 2019 17:15:59 +0200

Hi,

(slightly reordering quoted text)

Antoine Beaupre:
> So what will be the way forward for Debian users in buster?

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

Agreed.

> What does Tails do with this?

Tails only uses the torbrowser-launcher source package as a way to get
its AppArmor profiles… that we then patch heavily to make them
suitable for the weird way we install Tor Browser in Tails images.

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

That might be viable if the AppArmor profiles are disabled by default.

>  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

I'm curious: how would that installer differ from TBL in practice?

It seems to me that current TBL is essentially a one-shot installer +
a .desktop file + some AppArmor profiles.

>  4. drop TBL and shipp TBB directly in Debian

> 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? ;)

This has been discussed numerous times in the past. I don't recall the
details but what I remember is: it requires lots of hard work.
Personally, I don't think it's worth the effort. There's a ticket on
Tor's Trac about it, that might even have the relevant info.

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

Here's one more option:

5. Ensure Tor Browser can be installed in GNOME Software
   as a Flatpak or Snap

   This would cover the initial installation via usual means for
   non-technical users (GNOME Software). It provides sandboxing at
   least as good as AppArmor's, without the UX cost.

Cheers,
-- 
intrigeri

Message #20 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: intrigeri <intrigeri@debian.org>, 926042@bugs.debian.org

Cc: 926042@bugs.debian.org

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

Date: Fri, 03 May 2019 11:44:00 -0400

On 2019-05-03 17:15:59, intrigeri wrote:
> Hi,
>
> (slightly reordering quoted text)
>
> Antoine Beaupre:
>> So what will be the way forward for Debian users in buster?
>
>> TL;DR: TBL in backports or install by hand from TPO, AFAIK.
>
> Agreed.
>
>> What does Tails do with this?
>
> Tails only uses the torbrowser-launcher source package as a way to get
> its AppArmor profiles… that we then patch heavily to make them
> suitable for the weird way we install Tor Browser in Tails images.
>
>> 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)
>
> That might be viable if the AppArmor profiles are disabled by default.

Why would we disable apparmor profiles?

>>  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
>
> I'm curious: how would that installer differ from TBL in practice?
>
> It seems to me that current TBL is essentially a one-shot installer +
> a .desktop file + some AppArmor profiles.

I think TBL checks for updates at every start. Such a one-shot installer
would deploy TBB and get out of the way after.

>>  4. drop TBL and shipp TBB directly in Debian
>
>> 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? ;)
>
> This has been discussed numerous times in the past. I don't recall the
> details but what I remember is: it requires lots of hard work.
> Personally, I don't think it's worth the effort. There's a ticket on
> Tor's Trac about it, that might even have the relevant info.

"There's a ticket on Tor's Trac about it" is one of those statements
that sounds like "I have heard there is a green mouse crawling the
sewers of a small town in rural Kazhakstan with the encryption key to
the Russian nuclear arsenal".

In other words, do you have a ticket number because I have, like many
others, lost all hope of finding anything in Trac that I don't already
know where it is. ;)

>> Anyways, I would be glad to hear what the options are here and if this
>> inventory is complete!
>
> Here's one more option:
>
> 5. Ensure Tor Browser can be installed in GNOME Software
>    as a Flatpak or Snap
>
>    This would cover the initial installation via usual means for
>    non-technical users (GNOME Software). It provides sandboxing at
>    least as good as AppArmor's, without the UX cost.

That would be something I'd be happy to try, but it doesn't seem that
either is available now:

https://snapcraft.io/search?q=tor
https://flathub.org/apps/search/tor

(Observe, while you're there, how there are three possible "tor"
packages listed there, none of which are tor browser, and it's unclear
which one would be officially anything at all.)

Is there a ticket for "package TBB for flatpak or snap" on Trac as well?
;)

Thanks for your reply!

A.

-- 
I would defend the liberty of consenting adult creationists to practice
whatever intellectual perversions they like in the privacy of their own
homes; but it is also necessary to protect the young and innocent.
                        - Arthur C. Clarke

Message #25 received at 926042@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 926042@bugs.debian.org

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

Date: Fri, 03 May 2019 18:19:47 +0200

Hi,

Antoine Beaupré:
> On 2019-05-03 17:15:59, intrigeri wrote:
>>>  1. maintain through backports (seems to have been the option taken for
>>>     stretch)
>>
>> That might be viable if the AppArmor profiles are disabled by default.

> Why would we disable apparmor profiles?

See the "2." part of my original bug report.

>>>  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
>>
>> I'm curious: how would that installer differ from TBL in practice?
>>
>> It seems to me that current TBL is essentially a one-shot installer +
>> a .desktop file + some AppArmor profiles.

> I think TBL checks for updates at every start. Such a one-shot installer
> would deploy TBB and get out of the way after.

I see. I thought this check was removed at the same time as the code
that performs upgrades but I can very well be mistaken :)

>>>  4. drop TBL and shipp TBB directly in Debian
>>
>>> 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? ;)
>>
>> This has been discussed numerous times in the past. I don't recall the
>> details but what I remember is: it requires lots of hard work.
>> Personally, I don't think it's worth the effort. There's a ticket on
>> Tor's Trac about it, that might even have the relevant info.

> "There's a ticket on Tor's Trac about it" is one of those statements
> that sounds like "I have heard there is a green mouse crawling the
> sewers of a small town in rural Kazhakstan with the encryption key to
> the Russian nuclear arsenal".

Oh dear, how cute was this mouse? (</litteral mode>)

> In other words, do you have a ticket number because I have, like many
> others, lost all hope of finding anything in Trac that I don't already
> know where it is. ;)

It took me some time to find it but here it is:
https://trac.torproject.org/projects/tor/ticket/3994

> Is there a ticket for "package TBB for flatpak or snap" on Trac as well?
> ;)

For Flatpak there is https://trac.torproject.org/projects/tor/ticket/25578.

For Snap, there's been some discussion on tor-talk@ or tor-dev@
recently, after a Canonical employee served their marketing speech to
a Tor person.

Cheers,
-- 
intrigeri

Message #30 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 926042@bugs.debian.org

Subject: drawbacks of not having tbl in testing..

Date: Mon, 27 May 2019 09:56:31 +0000

[Message part 1 (text/plain, inline)]

hi,

i'm not sure I agree with the assumptions from this bug report but
anyway, i just want to point out that 'maintaining tbl in stretch via
stretch-backports' doesnt work because tbl is not in buster and thus, if
this bug gets retitled to 'tbl should not be part of bullseye',
maintaining tbl in buster via bullseye-backports will also not work.

(I just noted this bug now by chance, that's why I'm late to this party.)


-- 
tschau,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

[signature.asc (application/pgp-signature, inline)]

Message #35 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Ulrike Uhlig <ulrike@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 926042@bugs.debian.org

Subject: Re: Bug#926042: drawbacks of not having tbl in testing..

Date: Mon, 27 May 2019 14:18:54 +0200

Hi Holger,

On 27.05.19 11:56, Holger Levsen wrote:
> i'm not sure I agree with the assumptions from this bug report but

It would be useful to know with which statements or assumptions you do
not agree with and why - so that the discussion may become more
productive & helpful.

> anyway, i just want to point out that 'maintaining tbl in stretch via
> stretch-backports' doesnt work because tbl is not in buster and thus, if
> this bug gets retitled to 'tbl should not be part of bullseye',
> maintaining tbl in buster via bullseye-backports will also not work.

Do you have any suggestion on how to handle this?

Cheers,
Ulrike

Message #40 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Holger Levsen <holger@layer-acht.org>

To: 926042@bugs.debian.org

Subject: Re: Bug#926042: drawbacks of not having tbl in testing..

Date: Mon, 27 May 2019 13:02:33 +0000

[Message part 1 (text/plain, inline)]

On Mon, May 27, 2019 at 02:18:54PM +0200, Ulrike Uhlig wrote:
> It would be useful to know with which statements or assumptions you do
> not agree with and why - so that the discussion may become more
> productive & helpful.
 
"cannot be maintained in stable". I think this can at least be tried.
And IMO its better to have tbl in stable until the 5th or 7th
pointrelease and then have it removed (if it has to be done), than not
having tbl at all, never.

> > anyway, i just want to point out that 'maintaining tbl in stretch via
> > stretch-backports' doesnt work because tbl is not in buster and thus, if
> > this bug gets retitled to 'tbl should not be part of bullseye',
> > maintaining tbl in buster via bullseye-backports will also not work.
> Do you have any suggestion on how to handle this?

maintain tbl in stable.


-- 
tschau,
	Holger

-------------------------------------------------------------------------------
               holger@(debian|reproducible-builds|layer-acht).org
       PGP fingerprint: B8BF 5413 7B09 D35C F026 FE9D 091A B856 069A AA1C

Our civilization is being sacrificed for the opportunity of a very small number
of people to continue making enormous amounts of money...  It is the sufferings
of the many  which pay  for the luxuries  of the few...  You say  you love your
children  above all else,  and yet  you are stealing  their future  in front of 
their very eyes...

[signature.asc (application/pgp-signature, inline)]

Message #45 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Ulrike Uhlig <ulrike@debian.org>

To: Holger Levsen <holger@layer-acht.org>, 926042@bugs.debian.org

Subject: Re: [Pkg-privacy-maintainers] Bug#926042: drawbacks of not having tbl in testing..

Date: Fri, 14 Jun 2019 11:00:01 +0200

Hi!

On 27.05.19 15:02, Holger Levsen wrote:
> On Mon, May 27, 2019 at 02:18:54PM +0200, Ulrike Uhlig wrote:
>> It would be useful to know with which statements or assumptions you do
>> not agree with and why - so that the discussion may become more
>> productive & helpful.
>  
> "cannot be maintained in stable". I think this can at least be tried.
> And IMO its better to have tbl in stable until the 5th or 7th
> pointrelease and then have it removed (if it has to be done), than not
> having tbl at all, never.
> 
>>> anyway, i just want to point out that 'maintaining tbl in stretch via
>>> stretch-backports' doesnt work because tbl is not in buster and thus, if
>>> this bug gets retitled to 'tbl should not be part of bullseye',
>>> maintaining tbl in buster via bullseye-backports will also not work.
>> Do you have any suggestion on how to handle this?
> 
> maintain tbl in stable.

I have re-read intrigeri's arguments [1] and I entirely agree with his
assessments:

1. updates are required because of changes of GPG keys, TLS certs etc.
2. apparmor profiles regularly need updates because of upstream changes
   that we are generally not made aware of in time by upstream and only
   discover after the fact. There is a huge lack of communication here.
3. lack of time & energy to backport fixes on a regular basis.

i.e. I don't see us maintaining tbl in stable. That is certainly a sad
state. But reality is that most of us have too many other things on
their plate and do not see this as a priority. I volunteer to update the
Debian wiki page to document how to install torbrowser-launcher once
Buster is out.

That said, if *you* want to maintain tbl in stable I have no objections.

Cheers!
Ulrike

[1] Message-Id: <87zhpcb569.fsf@manticora>, email from march 30, 2019

Message #50 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Roger Shimizu <rogershimizu@gmail.com>

To: 926042@bugs.debian.org

Subject: Re: Bug#926042: torbrowser-launcher should not be included in Buster

Date: Sat, 27 Jul 2019 12:58:17 +0900

severity: -1 normal

Buster is released, so I guess it's okay to reduce the severity to let
it migrate to testing again.
I'll try to backports to stable and sloppy later.

Cheers,
-- 
Roger Shimizu, GMT -3 Curitiba
PGP/GPG: 4096R/6C6ACD6417B3ACB1

Message #57 received at 926042@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Roger Shimizu <rogershimizu@gmail.com>, 926042@bugs.debian.org

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

Date: Sat, 27 Jul 2019 12:12:25 -0300

Roger Shimizu:
> Buster is released, so I guess it's okay to reduce the severity to let
> it migrate to testing again.

Thanks a lot for caring about torbrowser-launcher!

FTR, I'm not enthusiastic at the idea of seeing it in testing and
backports (I suspect the reasons why torbrowser-launcher was not
suitable for Buster will still apply for Bullseye) but I can live with
it and I don't care enough about this topic to argue further.

Anyhow, maybe we can simply close this bug then? What's the value in
keeping it open at normal severity?

Cheers!
-- 
intrigeri

Message #62 received at 926042@bugs.debian.org (full text, mbox, reply):

From: Antoine Beaupré <anarcat@debian.org>

To: intrigeri <intrigeri@debian.org>, 926042@bugs.debian.org, Roger Shimizu <rogershimizu@gmail.com>, 926042@bugs.debian.org

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

Date: Mon, 29 Jul 2019 09:40:02 -0400

On 2019-07-27 12:12:25, intrigeri wrote:
> Roger Shimizu:
>> Buster is released, so I guess it's okay to reduce the severity to let
>> it migrate to testing again.
>
> Thanks a lot for caring about torbrowser-launcher!
>
> FTR, I'm not enthusiastic at the idea of seeing it in testing and
> backports (I suspect the reasons why torbrowser-launcher was not
> suitable for Buster will still apply for Bullseye) but I can live with
> it and I don't care enough about this topic to argue further.
>
> Anyhow, maybe we can simply close this bug then? What's the value in
> keeping it open at normal severity?

If anything, this bug provides a continuous track record of our attempts
at keeping this package alive in Debian. It is referenced upstream, for
example, in:

https://trac.torproject.org/projects/tor/ticket/3994

intrigeri: how does Tails ship TBB nowadays? The above bug report says
something about an Iceweasel package 6 years ago, but surely that can't
be up to date anymore... ;) Earlier in May you mentioned a "weird way"
without going into details...

It seems to me we have a common problem across distributions (and
upstream) that we should figure out how to tackle. It would be too bad
if this problem would just disappear under the rug while it's a real
issue for our users still...

A.

-- 
A ballot is like a bullet. You don't throw your ballots until you see
a target, and if that target is not within your reach, keep your
ballot in your pocket.
                         - Malcom X

Message #67 received at 926042@bugs.debian.org (full text, mbox, reply):

From: intrigeri <intrigeri@debian.org>

To: Antoine Beaupré <anarcat@debian.org>, 926042@bugs.debian.org, Roger Shimizu <rogershimizu@gmail.com>

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

Date: Mon, 29 Jul 2019 20:18:46 -0300

Antoine Beaupré:
> intrigeri: how does Tails ship TBB nowadays? The above bug report says
> something about an Iceweasel package 6 years ago, but surely that can't
> be up to date anymore... ;) Earlier in May you mentioned a "weird way"
> without going into details...

See the "3.6.13 Tor Browser" section of
https://tails.boum.org/contribute/design/ (and the code it points to).
I'm afraid this won't be particularly useful in a Debian context, though.

> It seems to me we have a common problem across distributions (and
> upstream) that we should figure out how to tackle. It would be too bad
> if this problem would just disappear under the rug while it's a real
> issue for our users still...

FWIW, I'm putting my eggs in the Flatpak basket (and intend to work on
this at some point in the next 1-2 years).

Cheers,
-- 
intrigeri

Send a report that this bug log contains spam.