[HOME] [DOWNLOAD] [DOCS] [BLOG] [SUPPORT] [TIPS] [ISSUES] [Priority Support]

Tor Releases Discussion

#1

New stable Tor releases, with security fixes: 0.3.1.9, 0.3.0.13, 0.2.9.14, 0.2.8.17, 0.2.5.16

TROVE-2017-009: Replay-cache ineffective for v2 onion services
    severity: medium
    whonix impact: replay attack against v2 hidden services. was already possible without this regression.
TROVE-2017-010: Remote DoS attack against directory authorities
    severity: medium
    whonix impact: directory authorities only
TROVE-2017-011: An attacker can make Tor ask for a password
    severity: high
    whonix impact: none (tor daemons not affected)
TROVE-2017-012: Relays can pick themselves in a circuit path
    severity: medium
    whonix impact: relays only; dangerous if running relay & onion on same tor (not recommended)
TROVE-2017-013: Use-after-free in onion service v2
    severity: high
    whonix impact: v2 hidden services; difficult to trigger remotely

Takeaways:

  • upgrade to new onions (v3 hidden services) when 0.3.2.x is stable.
  • do not run mixed tor instance:
    • client + relay (due to permanent entry guards)
    • client + hidden service
    • relay + hidden service

@torjunkie and I have been running 0.3.1.x from torproject repo for some time now (1 month+) without any issues. No experience with recent 0.2.9.x versions.

#2

Created ticket: Upload all stable binaries to torproject debian repository
(https://trac.torproject.org/projects/tor/ticket/24482)

#3

Yes, should be uploaded to Whonix repository ASP.

Tor Project jessie repository latest version is:

Get:1 http://deb.torproject.org/torproject.org jessie/main i386 tor i386 0.3.1.8-2~d80.jessie+1 [1649 kB]

Looks like Torproject jessie repository gets no longer maintained?

#4

Stretch hasn’t been updated yet either:

https://deb.torproject.org/torproject.org/dists/stretch/main/binary-amd64/Packages

Package: tor
Version: 0.3.1.8-2~d90.stretch+1
Architecture: amd64

#5

https://trac.torproject.org/projects/tor/ticket/24482 is resolved wontfix - too much work - so back where we started.

arma has the impression that Debian stable will follow LTS releases going forward. I think the easiest (less work for Patrick) and most trustful (Whonix doesn’t touch Tor) and safest (fast update from Debian repo) is to follow LTS release by Whonix default. That will make many “hardened / feature-hungry” users unhappy. But it’s not that difficult to switch repo to torproject and get the latest stable version - the caveat is that breakage is resolved by user / community.

This means

Whonix-13    Tor    0.2.5 LTS  (no changes now but hypothetically)
Whonix-14    Tor    0.2.9 LTS

@torjunkie @HulaHoop

#6

Generally, versions from Debian are preferred to reduce maintenance burden.

The original reason to use Tor versions from deb.torproject.org no longer exists.

Two problems:

  • Problem is Whonix 13 jessie repository is now on 0.3.1.8-2~d80.jessie+1 so a usual apt-get dist-upgrade cannot downgrade them to 0.2.9 LTS. So perhaps we’d add special instructions for downgrade?
  • anon-connection-wizard needs 0.3.1. //cc @torjunkie
#7

That is correct. Specifically because anon-connection-wizard is using Tor 0.3.1's torrc.d feature. If we eventually really decided to stick with Tor 0.2.9 in Whonix 14:

  1. I will try to rewrite the anon-connection-wizard’s torrc IO part; however, eventually we will use torrc.d.
  2. I will try to make sure no Whonix document encourages users to use torrc.d feature.
#8

Maybe too much trouble to implement for Whonix 13. If you don’t plan on supporting upgrade path for 13 -> 14, then not really an issue since 13 is soon-to-be EOL.

#9

There has to be a an upgrade path. It was functional.

#10

No, deb.torproject.org is not dead. It will continue to have one version of Tor - the latest stable binary. 0.3.1.9 is on it now.

But iry is correct, the LTS versions that get sent to Debian are delayed by usual process. (stretch is still on 0.2.9.12 and waiting for 0.2.9.14). iry has a good point that at least LTS should be hosted by TPO. LTS users should not be penalized (relative to latest stable users) by having an additional entity in the chain of trust (and additional delays).

#11

Hi @entr0py !

The one in the ticket is irl, not me. :slight_smile:

#12

Rubs eyes. :slight_smile: Never turn down a compliment!

#13

Reply to here because it is more on topic.

Here is my understanding:

  1. deb.torproject.org, no matter jessie or stretch, will only contain the latest stable which is 0.3.1.9 for now.
  2. Debian repo, will only contain the LTS which is 0.2.9 for stretch.
  3. Whonix does not want automatically update to the latest stable in TPO repo because it may cause breakage to Whonix.
  4. Therefore, Whonix decides to stick with the LTS.
  5. Although LTS is only available in Debian repo for now, it is better to have LTS in TPO repo, too. Because TPO repo can be updated faster than Debian repo.

What confuses me is why “the latest stable in TPO may cause breakage in Whonix”. From my understanding, if it is marked as stable, it should not cause breakage, otherwise, it should not be marked as stable.

My guess is the “stable” means it is stable in Debian, not necessarily means “stable” in Whonix. But did a latest stable in TPO break Whonix before? If so, if I am going to be a tester of the Tor nightly build on Whonix, how likely they are going to fix the bug that is Whonix-only before marking it as “stable”? (My guess is very unlikely).

#14

Yes, but I don’t know / remember the specifics (Patrick’s answer). TPO does not guarantee compatibility with Whonix. The greatest concern is major upgrades 0.0.x as opposed to minor updates 0.0.0.x.

They are very accomodative toward the Whonix use-case (transparent / isolating proxy) so there is a good chance that they will fix.

#15

entr0py:

They are very accomodative toward the Whonix use-case (transparent / isolating proxy) so there is a good chance that they will fix.

Thank you very much for your answer, @entr0py !

Therefore, another solution to the problem is Whonix can stick with the
latest stable from the TPO repo as long as there are enough Whonix
people who can actively test tor nightly build on Whonix and report bugs
to TPO?

Yes, I can be one of them :slight_smile: but we still have to have enough eyes to
find bugs.

(I am not opposed to stick with LTS. I just proposed another solution. :slight_smile: )

#16

Good.

Correct.

No, that’s not how it is atm implemented. Versions are downloaded from deb.torproject.org, verified to work, them migrated to deb.whonix.org.

Yes, that would help a lot a lot. The earlier we can report any breakage to TPO, the lesser the chance that we end up with a stable version / recommended upgrade that is not fit for upload to deb.whonix.org since it would break connectivity or apt-get.

#17

tor 0.3.1.9-1~d80.jessie+1 uploaded to:

  • jessie-proposed-updates
  • testers
  • developers
#18

Could you please summarize this development discussion and add here https://www.whonix.org/wiki/Dev/Tor#Tor_Version?

#19

Patrick Schleizer:

No, that’s not how it is atm implemented. Versions are downloaded from deb.torproject.org, verified to work, them migrated to deb.whonix.org.

I see! So in the future, there are three options to make Tor available
in Whonix:

  1. Versions are downloaded from deb.torproject.org, verified to work,
    them migrated to deb.whonix.org.
  • Pros: flexibility in version, guarantee only stable version will be
    uploaded
  • Cons: need a few testers, need manually upload, Whonix touches Tor
  1. Use LTS in Debian Stable repo and do not worry about anything.
  • Pros: Not much work for Whonix
  • Cons: No new features
  1. Use latest stable in TPO repo and have tester use Tor nightly build
    in Whonix and report bug to TPO.
  • Pros: Latest features
  • Cons: Need a lot of active testers to guarantee the build is stable
    for Whonix before it uploaded to TPO repo, otherwise breakage will happen

What is our preference?

Yes, that would help a lot a lot. The earlier we can report any breakage to TPO, the lesser the chance that we end up with a stable version / recommended upgrade that is not fit for upload to deb.whonix.org since it would break connectivity or apt-get.

If option 3 is chosen, maybe a brief Whonix Blog post and Wiki doc
describing how to do this step by step will draw more people’s attention
to be a Tor nightly build tester?

#20

Thanks to everyone all for asking, this helps getting this documented so any decision can be reconsidered!

You know, as time passes by, without having proper developer documentation, it’s easily forgotten why things are now like they are now.