For future reference you should use the forum search engine at the top right of your screen before you create a new post. If you had entered “tor unrecommended” or "unrecommended " you would have found this duplicate post which still applies to your questions.
boring, now is the whonix update with 0.2.9.10 and the new one with many security fixes is 0.2.9.12.
Why goes Whonix the unsafe way and dont update directly to the newest stable? and then asks for a donation ^^ for his permernent out-of-date product pfff
I agree that we should update to 0.2.9.12 as a best practice.
There is one security fix in 0.2.9.11 and one in 0.2.9.12. Both only affect users running onion / hidden services.
0.2.9.11 fixes TROVE-2017-005: “a bug that would allow an attacker to remotely crash a hidden service with an assertion failure.”[1]
0.2.9.12 fixes TROVE-2017-008: “a security bug that affects onion services running with the SafeLogging option disabled.”[2] (SafeLogging is enabled by default.)
Update to latest stable version (currently 0.3.0.11 0.3.1.7) by installing anon-shared-build-apt-sources-tpo [3] or by manually adding torproject repos. Compatibility with Whonix not guaranteed.
It’s not “his” product. It’s ours. And you’re welcome to support its continued existence by making suggestions like you did at any time. You may also submit pull requests, suggest new tickets, or donate so others can work on development. How to contribute.
Tor 0.3.0.x introduced an updated directory authentication mechanism as well as new guard selection algorithms. Tor 0.3.1.x introduced compact directory formats and network padding (which requires both clients and relays to be updated to be functional).
Since these are major new features, these clients should be tested before being uploaded to Whonix stable. My guess is that Whonix will stay on 0.2.9.x until Whonix 14. (FYI, 0.2.9.x is an LTS release and will remain officially supported until Jan 2020). If you’d like to help test, simply clone your whonix-gw template and follow the instructions above to upgrade to 0.3.1.x.
It’s time consuming maintaining Whonix stable as well as developing the new version based on a newer version of Debian.
There are no automated tests to make sure upgrades don’t break connectivity for everyone and no code contributions for that sort either.
However… The less time I spend on forum support and wiki, the better the quality by the community. Amazing! (Unfortunately, the same isn’t happening with the code.)
We could also stay on tor 0.2.5.[…] as long as Whonix is jessie based and then tor 0.2.9.[…] as long as Whonix is stretch based, i.e. using the stable versions maintained by Debian, see:
This was the case in earlier versions of Whonix but then things happened creating a strong urge to use the version from deb.torproject.org. I was wondering if it was best to move Whonix back to that method if possible.
The best option would be if we could pin major version (0.2.9.*) in apt/preferences but torproject’s repo only contains the latest stable version so we would lose updates as soon as 0.3.0.* came out.
Will see if I can find out why they don’t keep all supported versions in their repo (or maybe I’m doing it wrong.)
You probably know but in case anyone is wondering: an automatic 0.2.9 -> 0.3 upgrade of Tor could break connectivity for Whonix users. (Happened in past. AppArmor, configs and whatnot.) That’s why it’s not as easy as enabling torproject’s repository by default for everyone.
Because then we could stay with the version from Debian.
Given this version of Tor supports padding, I think we should recommended users set the following in their torrc file for better security against network analysis:
Connections between clients and relays now send a padding cell in each direction every 1.5 to 9.5 seconds (tunable via consensus parameters). This padding will not resist specialized eavesdroppers, but it should be enough to make many ISPs’ routine network flow logging less useful in traffic analysis against Tor users.
Padding is negotiated using Tor’s link protocol, so both relays and clients must upgrade for this to take effect. Clients may still send padding despite the relay’s version by setting ConnectionPadding 1 in torrc, and may disable padding by setting ConnectionPadding 0 in torrc.
If you agree, I’ll edit the wiki here (they can add an additional line under the Sandbox 1 entry):