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

phabricator-migrator · February 19, 2024, 5:47pm

Information

ID: 417
PHID: PHID-TASK-rkeigwhbn4le6kau32jg
Author: Patrick
Status at Migration Time: resolved
Priority at Migration Time: Normal

Description

Prerequisite knowledge:

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?~~

Comments

Patrick

2015-12-15 23:28:11 UTC

Patrick

2015-12-25 16:36:52 UTC

I can’t host Tor Browser binaries.

A new package has been created, but it’s still boilerplate without binaries:
GitHub - adrelanos/tb-binary: Deprecated attempt - Tor Browser Bundle (TBB) binaries - https://phabricator.whonix.org/T417 - This package is produced independently of, and carries no guarantee from, The Tor Project.

I can’t host this for trademark issues, see:
Tor Browser Essentials

Also source code license is too difficult to get right, see:
tb-binary/debian/copyright at master · adrelanos/tb-binary · GitHub

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

2016-01-05 16:17:47 UTC

Patrick

2016-01-05 16:30:02 UTC

Patrick

2016-01-05 23:19:00 UTC

Patrick

2016-01-05 23:21:21 UTC

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.

marmarek

2016-01-06 00:33:18 UTC

Patrick

2016-01-06 16:33:54 UTC

Patrick

2016-01-06 17:24:12 UTC

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.

mfc

2016-01-06 17:36:50 UTC

Patrick

2016-01-06 19:12:18 UTC

marmarek

2016-01-06 22:17:28 UTC

! 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.

Patrick

2016-01-06 22:25:47 UTC

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: headless, unattended TBB updates [by script] (#17136) · Issues · Legacy / Trac · GitLab) 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.

Patrick

2016-01-06 22:36:20 UTC

avoid requirement for sudoers exception thanks to suggestion by @marmarek ;
work on up to date versions of Tor Browser in newly created AppVMs
avoid requirement for sudoers exception thanks to suggestion by @marm… · Kicksecure/tb-updater@e3c3b0b · GitHub

Patrick

2016-01-07 18:22:00 UTC

marmarek

2016-01-07 22:54:53 UTC

Patrick

2016-01-08 02:34:28 UTC

Patrick

2016-01-08 02:38:16 UTC

Patrick

2016-01-08 02:55:33 UTC

mfc

2016-01-08 11:45:50 UTC

Patrick

2016-04-08 21:06:25 UTC

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

/usr/share/tb-updater/tbb_hardcoded_version

https://phabricator.whonix.org/T417
moved hardcoded version for postinst into its own file for easier mai… · Kicksecure/tb-updater@e9469d6 · GitHub

Patrick

2016-04-26 05:22:38 UTC

Patrick

2016-04-29 04:55:37 UTC

Patrick

2016-04-30 00:42:07 UTC

Patrick

2016-04-30 00:52:55 UTC

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:

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

Implement the solution.

Patrick

2016-05-04 21:51:43 UTC