Ah, great, thanks for summarzing it!
(I am keeping releasing tb-updater package upgrades with bumped (stable) hardcoded version numbers (
tbb_hardcoded_version), because I am not trusting the auto detection is going to work forever. When RecommendedTBBVersions format changes as it did a few times in past, the version auto detection breaks. [
tbb_hardcoded_version is set to the stable, since That is the recommended version by Torproject, most stable, least maintenance overhead.])
Another future feature could be to ship two versions of
tbb_hardcoded_version. One for default, for most, for stable users and another one with the most reasonable alpha (would be now: hardened). I didn’t go for this, because it would increase maintenance overhead. (More tb-upgrader stable upgrades, not only for new stable Tor Browser releases, but also for each new alpha.)
An alternative additional(!) future feature [disabled by default] could be to auto detect the highest available version number of a configurable
release channel (terminology used by Tor Browser about menu) (for example: stable or hardened). tb-updater would also need a feature to auto run. But when, and how(!) would in Qubes TempalteVMs be a good time to auto run? The how is a big question mark. There are no hooks into apt-get update or apt-get dist-upgrade. Only dpkg hooks. And running tb-updater every time dpkg runs seems wrong.
Right. I don’t see any way around that as of Whonix 13. And for Whonix 14, we’d still need to draft a feature (as per above).
As of Whonix 13 without any of the features described above, I think tb_install_follow=false should be mandatory for anyone wanting to use hardened. (With a reminder to recheck for Whonix 14. Maybe we’ll think of something.)