Design documentation:
Platform support for Tor Debian (deb) packages provided by the deb.torproject.org APT repository has been reduced by The Tor Project.
- amd64
- arm64
- armel
- armhf
- i386
- amd64
- arm64
- i386
Namely, platform support for armel and armhf has been removed. Therefore these can no longer be downloaded from deb.torproject.org and uploaded to deb.whonix.org.
It always takes a few days between a release announcement on blog.torproject.org and deb packabe availability from deb.torproject.org.
Versions available from deb.torproject.org can be seen here:
https://deb.torproject.org/torproject.org/dists/buster/main/binary-amd64/Packages
New Releases: Tor 0.3.5.12, 0.4.3.7, and 0.4.4.6
Uploaded Tor 0.4.4.6 to testers repository just now.
armhf and armel are on their way out anyhow. Do Debian repos support all Debian archs? This is useful when building Whonix for non conventional platforms like POWER. Can this be easily selected during build time?
1 Like
All, don’t know. But more platforms, yes.
Even if the answer for that platform is “yes”, could be that Tor won’t start if Whonix is using Tor configuration features only available in a newer Tor version. Maybe %include is unsupported in Debian buster version. I don’t test that since design was decided as per above post and compatible with all platforms not a higher priority goal.
Currently no. But nobody ever noticed for any unsupported platforms. Possible to add code to skip that Tor package from deb.torproject.org download code.
Updated https://www.whonix.org/wiki/Dev/Tor#Tor_Version - most noteably:
2. Use latest stable in TPO repository and allow testers to use the Tor nightly build in Whonix ™, with bug reporting bug to TPO
- Advantages: Latest features, better security, improved Tor Browser compatibility (using
SocksPortwith flags and even better connectivity performance). [3]- Disadvantages:
- From the Whonix ™ perspective, these packages are uploaded to
deb.torproject.orgat random times. These packages are not guaranteed to be compatible with Whonix ™. While there are no security concerns, these packages could break a system’s apt-get package management (due to incompatible dependencies) or connectivity, in case Tor refuses to start. This can arise due to a configuration incompatibility in a newer version of Tor, or for other reasons such as systemd or apparmor related changes.- In May 2021 a transient repository issue [archive] broke [archive] Whonix ™ build process.
- There is nothing similar to
snapshot.debian.org. Keeps changing (newer versions being added). Hence, can introduce build issues such as above. Unsuitable for reproducible builds / Verifiable Builds.- Porting to other architectures issues.
- Only available for the
i386,amd64,arm64architectures.- Introduces differences / issues such as for example for the
ppc64elplatform. [4]
Therefore for milestone_whonix_16 (Debian bullseye based) considering to go back to method:
1. Use the Tor LTS version from the official Debian package repository:
packages.debian.org
Downgrading to Tor version 0.4.5.7-1 as frozen, maintained by Debian for the bullseye release.
Though, the following could become an issue:
Missing new versions:
[…] Latest features, better security, improved Tor Browser compatibility (using
SocksPortwith flags and even better connectivity performance). [3]
I guess if that happens, have to go back to option 2.
Related:
Tor Upgrades
2 Likes
Likely going for tor (0.4.5.9-1) from Debian -- Details of package tor in bullseye in Whonix 16 (Debian bullseye based).
(Pros and cons above in this forum thread.)
Yes.
One obvious downside of sticking to Debian’s (snail pace) Tor version: missing security/privacy advantages of later Tor releases.
Do we really want to wait two years to benefit from these kinds of advantages i.e. when a new Debian version is released? This negative will only become larger as the Debian stable version ages.
(my bold)
https://blog.torproject.org/tor-0.4.7.1-alpha-released
This version is the first alpha release of the 0.4.7.x series. One major feature is Vanguards Lite, from proposal 333, to help mitigate guard discovery attacks against onion services. It also includes numerous bugfixes.
&
Major features (Proposal 332, onion services, guard selection algorithm):
Clients and onion services now choose four long-lived “layer 2” guard relays for use as the middle hop in all onion circuits. These relays are kept in place for a randomized duration averaging 1 week. This mitigates guard discovery attacks against clients and short-lived onion services such as OnionShare. Long-lived onion services that need high security should still use the Vanguards addon (GitHub - mikeperry-tor/vanguards: Vanguards help guard you from getting vanned...). Closes ticket 40363; implements proposal 333.
1 Like
Technically isn’t the vanguard plugin applying the longer turnover to onions for all of them?
1 Like
The specific feature:
We’re using “vanguards full” (not lite):
Should be better?
I wonder if it would make sense to install anon-shared-build-apt-sources-tpo by default, and to have Whonix Gateway depend on the exact tor version that’s currently bundled in the latest stable Tor Browser release?
Whenever the Whonix Gateway tor version is out of sync with the mainline Tor Browser tor version, it’s a potential fingerprinting hazard.
That would come with some disadvantages documented under Tor integration in Whonix ™ Development Notes starting from:
2. Use latest stable in TPO repository […]
I am not saying it shouldn’t be done. Only linking to previous thoughts to consider before making such a big change.
What versions are provided by deb.torproject.org is not being kept fully synchronous. It’s contributed, maintained by Peter Palfrader (also a Debian developer) last time I checked. Great year long service btw! However, The Tor Project does not orchestrate TBB and deb.torproject.org releases being always having the same/compatible versions.
By hard coding a version dependency it would break the build process as soon as deb.torproject.org changes. When deb.torproject.org is changed is unpredictable form my point of view.
Indeed. A price to pay for Tor / Tor Browser isolation. But I don’t think it can be resolved without having Tor Browser + Debian tor package being properly maintained in packages.debian.org (which is unfortunately highly unlikely for Tor Browser, not happening for a decade or so) while deb.torproject.org can have different versions (mostly Tor Browser using a newer version than available in deb.torproject.org but it could also happen vice versa) because it’s all different development teams and release cycles, deb.torproject.org, Tor core, TBB.
2 Likes
https://github.com/Whonix/Whonix/commit/a9034f6238997de4ecdfab4def96cb1a219aeab4
https://github.com/Whonix/Whonix/commit/5542f3491045ac2ef9db42f8ffcc112baef4cd7b
handy for reference:
- Index of /torproject.org/dists/bullseye/main/binary-amd64
- https://deb.torproject.org/torproject.org/dists/bullseye/main/binary-amd64/Packages
Above link still lists:
Version: 0.4.6.9-1~d11.bullseye+1
In other words, not yet available from deb.torproject.org.
Noted.
Version 0.4.7 will be be stable soon enough.
2 Likes