Page MenuHomePhabricator

up to date versions of Tor Browsers in newly created AppVMs inherited from updated TemplateVMs
Closed, ResolvedPublic

Description

Prerequisite knowledge:
https://www.whonix.org/wiki/Dev/Qubes#tb-updater_vs_TemplateVM

Goal:
After updating the TemplateVM, at least newly created AppVMs based on the updated TemplateVM should come with an up to date version of Tor Browser.

Non-goal:
Updating existing installations of Tor Browser in existing AppVMs. [Economically impossible in the absence of The Tor Project maintaining a proper Debian package while preserving user data (bookmarks, etc.).] Those still have to be updated with Tor Browser's internal updater. If further discussion on this non-goal is required, a separate discussion should be opened.

Alternative technical task title:
ship Tor Browser tarballs in Qubes TemplateVMs in /var/cache/tb-binary and extract in AppVMs at boot time to user's home folder

Implementation:

  • in tb-updater postinst / update-torbrowser

Deprecated:

  • Create a package tb-binary, that ships a folder /var/cache/tb-binary that includes the Tor Browser tarball tor-browser-linux64-x.x_en-US.tar.xz as well as signature tor-browser-linux64-x.x_en-US.tar.xz.asc.
  • During boot of AppVMs, a script should check if Tor Browser is already installed in user's home folder. And if not, verify [reusing tb-updater code] and extract Tor Browser from /var/cache/tb-binary to user's home folder.
    • [The verification makes shipping malicious files in the tb-binary package less attractive.]
  • Configurable through /etc/torbrowser.d folder (can be turned off).

Questions:

  • Is there any more appropriate folder than /var/cache/tb-binary as per FHS?

Details

Impact
Normal

Event Timeline

Patrick raised the priority of this task from to Normal.
Patrick updated the task description. (Show Details)
Patrick added projects: Qubes, Whonix 13, tb-updater.
Patrick set Impact to Normal.
Patrick added subscribers: Patrick, marmarek, nrgaway and 3 others.
allow storing downloaded archives in arbitrary folders

https://phabricator.whonix.org/T417

https://github.com/Whonix/tb-updater/commit/1c85166a20af638ceab25900fb75b9f62a9645d7

I can't host Tor Browser binaries.

A new package has been created, but it's still boilerplate without binaries:
https://github.com/adrelanos/tb-binary

I can't host this for trademark issues, see:
https://www.whonix.org/wiki/Tor_Browser#Not_installed_by_Default_Footnote

Also source code license is too difficult to get right, see:
https://github.com/adrelanos/tb-binary/blob/master/debian/copyright

And I don't know if there is such a thing as a compilation license of the binary itself.

This is going to be very ugly. This will bloat Whonix source code size. All the old binaries of Tor Browser will be kept by git as newer versions are added. Removing them, rewriting git history, would require to use ugly things such as git push --force and git merge --force. I really appreciated suggestions on how this could be implemented less ugly.

Patrick claimed this task.

As discussed at 32c3, a tb-binary package is the wrong way to implement this. Instead, Tor Browser will be downloaded during postinst of tb-updater. Will be done in T461.

Patrick updated the task description. (Show Details)

This isn't done. Just the implementation details changed.

TLDR:
Would installation of Whonix packages to build Qubes-Whonix happen inside a Qubes TemplateVM* or inside a chroot? @marmarek

*Or StandaloneVM. [Or TemplateBasedVM for testing purposes.]

Long:
Background:
I need to know this for T461 (Installation from Repository / proverbial "sudo apt-get install whonix"). The initial installation of Tor Browser either happens inside a TemplateVM or a chroot.

More background:
The tb-updater postinst mechanism to download Tor Browser archives to /var/cache/tb-binary makes only sense in a TemplateVM. So I will detect this from the tb-updater postinst script. Building Whonix may be a special case. The initial installation of Tor Browser might happen from within a chroot. Depending on how we want this ticket to work out.

Even more background:
The tb-updater postinst mechanism to download Tor Browser archives to /var/cache/tb-binary makes only sense in a TemplateVM.

  • TemplateBased or Standalone AppVMs would just update using Tor Browser's internal updater. Or download a new Tor Browser using tb-updater to the home folder.
  • TempalteVMs would store Tor Browser archives to /var/cache/tb-binary, so newly created TemplateBased [or Standalone] AppVMs would start with an update to date version of Tor Browser, which is the goal of this ticket.
Would installation of Whonix packages to build Qubes-Whonix happen inside a Qubes TemplateVM* or inside a chroot? @marmarek

chroot.

Please leave some feedback on the usability impact here. I appreciated a small "okay" message. @bnvk @mfc @marmarek
(To avoid spending time on implementing something we later decide to not enable by default.)

Implementing this feature would make upgrading the Qubes-Whonix-Workstation on every tb-updater package upgrade (on new Tor Browser releases) at least 6 minutes slower. On slower [Tor] connections it could easily take 12 or more minutes.

The worst case here would be users that only use a single Qubes-Whonix-Workstation TemplateBased AppVM and sticking with it for a long time. These would not benefit from this feature.

[Presuppose they keep their TempalteVM up to date.]
Users who would benefit from this feature would be users who often create new AppVMs. These would start with an up to date version of Tor Browser when they create new AppVMs. Therefore would not need to update Tor Browser using Tor Browser's internal updater in newly created AppVMs.

Very likely (depending on how DispVMs will be implemented in future), this feature is required to have Qubes-Whonix-Workstation based DispVMs start with up to date versions of Tor Browser.

Speaking here about the default settings. This could be disabled by advanced users as documented.

Don't worry. It's not rocket science to implement this. And fun work.

Patrick (Patrick Schleizer):

Very likely (depending on how DispVMs will be implemented in future), this feature is required to have Qubes-Whonix-Workstation based DispVMs start with up to date versions of Tor Browser.

Is this the case with how DispVMs are currently implemented? It would be
ideal to get to the state where the user can create Tor Browser DispVMs
that are up-to-date.

mfc (mfc):

Is this the case with how DispVMs are currently implemented?

Yes.

It would be ideal to get to the state where the user can create Tor Browser DispVMs that are up-to-date.

If nothing goes wrong, this is close (Whonix 13).

In T417#7845, @Patrick wrote:

Implementing this feature would make upgrading the Qubes-Whonix-Workstation on every tb-updater package upgrade (on new Tor Browser releases) at least 6 minutes slower. On slower [Tor] connections it could easily take 12 or more minutes.

IMHO not a big problem. And if it is, user can disable this feature (as you pointed in documentation).

The worst case here would be users that only use a single Qubes-Whonix-Workstation TemplateBased AppVM and sticking with it for a long time. These would not benefit from this feature.

How does Tor Browser internal updater work? Maybe it can be configured to look for a package downloaded by tb-updater package first? Just an idea, ignore if not trivial.

Very likely (depending on how DispVMs will be implemented in future), this feature is required to have Qubes-Whonix-Workstation based DispVMs start with up to date versions of Tor Browser.

Your idea of DispVMs (read-only private image, instead of no private image) makes it not so obvious. If DispVM could be started out of any AppVM, then user could have already installed Tor Browser in that VM (used for DispVM).
But generally IMHO we should think how to make use of already downloaded Tor Browser in that case. To simplify update procedure. It would be terrible UX if user is required to update some applications separately (->manually) from package manager (->done by management stack in the future as one-click button for the whole system).

So, generally I like the approach presented here.

Thanks! So I will work on completing this feature.

In T417#7852, @marmarek wrote:

How does Tor Browser internal updater work? Maybe it can be configured to look for a package downloaded by tb-updater package first? Just an idea, ignore if not trivial.

It uses different files for that. .mar files. And Firefox's update magic. Really non-trivial. Unfortunately. Otherwise I also had in mind to initiate updating Tor Browser automatically in AppVMs [in background] by starting/scripting its updater. Too fragile/difficult. (rejected ticket: https://trac.torproject.org/projects/tor/ticket/17136) Would have to manually figure out the correct .mar file. Could not use the internal logic to fetch the right one as this is not provided by the command line interface.

avoid requirement for sudoers exception thanks to suggestion by @marmarek ;
work on up to date versions of Tor Browser in newly created AppVMs

https://github.com/Whonix/tb-updater/commit/e3c3b0b816cba1a65992b8810517f9f2c76b181e

Do you think it would be crazy to download and extract Tor Browser to /etc/skel rather than /var/cache/tb-binary? It would violate Debian policy. (Non-packaging software writing to /etc.) But it would be a bit simpler. Then /usr/lib/anon-base-files/first-boot-skel would automagically keep care of copying Tor Browser to the user's home. No separate tb-updater specific /var/cache/tb-binary to user home population systemd service required then. @marmarek

I'm not sure. Technically it sounds good, but I feel it's something wrong...

Patrick changed the task status from Open to Review.Jan 8 2016, 2:55 AM

It works! We have Tor Browser in Qubes-Whonix-Workstation DispVMs now!

moved hardcoded version for postinst into its own file for easier maintenance

/usr/share/tb-updater/tbb_hardcoded_version

https://phabricator.whonix.org/T417

https://github.com/Whonix/tb-updater/commit/e9469d65c457dec971a2ce31521f1707a7d69deb

Patrick changed the task status from Review to Open.Apr 29 2016, 4:55 AM

TODO

1)

On manual run of update-torbrowser in TemplateVM stores Tor Browser still in the home folder, so up to date versions of Tor Browsers in newly created AppVMs are not inherited from updated TemplateVMs.

(Currently only works when update-torbrowser is run during tb-updater package upgrade.)

Somewhat counter intuitive. Probably. And should be fixed.

2)

Minor, cli output should explain hardcoded version number.

Problem:

Upgraded TemplateVMs - i.e. installed prior Whonix 13 - will still have Tor Browser installed in their home folder. Since the home folder of TemplateVMs is still always and by default inherited by TemplateBasedVMs as of Qubes R3.1 (R3.2 probably also), this feature does not work. (Because TemplateVM home contains old version, which gets inherted by TemplateBasedVM and the new tb-updater first boot population systemd service will not touch existing folders.)

TODO:

  • 1) Decide how to resolve the station. Either
    • a) delete folders ~/.tb and ~/cache/tb using a maintainer script during template upgrade
    • b) or better move these folders somewhere out of the way, to avoid the user having data loss (customized Tor Browser in TemplateVM) [and avoid eventual bugs from causing damage such as running the deletion code in a non-TemplateVM]
    • c) not automate it, but inform the user about this inside the tb-updater output
    • d) do nothing about it, wait and see if Qubes R4 will no longer inherit TemplateVMs home folder
  • 2) Implement the solution.
Patrick changed the task status from Open to Review.May 4 2016, 9:58 PM