There is a security problem for people offering hidden services through the Tor network that is only fixed in the latest alpha. The description from the Tor info mail: "Versions affected: all stable versions, and all experimental versions up through 0.1.1.10-alpha. Impact: If you offer a Tor hidden service, an adversary who can run a fast Tor server and who knows some basic statistics can find the location of your hidden service in a matter of minutes to hours. Solution: You have three options: 1) Upgrade to Tor 0.1.1.12-alpha from the Tor download page [1]. You're
There is a security problem for people offering hidden services through the Tor network that is only fixed in the latest alpha. The description from the Tor info mail: "Versions affected: all stable versions, and all experimental versions up through 0.1.1.10-alpha. Impact: If you offer a Tor hidden service, an adversary who can run a fast Tor server and who knows some basic statistics can find the location of your hidden service in a matter of minutes to hours. Solution: You have three options: 1) Upgrade to Tor 0.1.1.12-alpha from the Tor download page [1]. You're all set, though be aware that this is an alpha release so there may be other bugs. You may also want to look through the release notes [2]. 2) Turn off your hidden service until the final 0.1.1.x release is out. It may be several months. 3) Stick with Tor 0.1.0.16 and manually configure a half dozen EntryNodes. See the FAQ entry [3] for some hints about how to do this. The details: Tor researchers Lasse Øverlier and Paul Syverson have confirmed that a previously theoretical attack on Tor works very well in practice. Specifically, they found that a malicious Tor server can locate a hidden service more quickly than was previously believed. The attack is simple: access the hidden service repeatedly, and keep track of who builds circuits through you shortly after each access. Because you can induce your victim to build a new circuit on demand, eventually one of his circuits will start at your node. To slow this attack, our latest experimental release implements a new feature called "guard nodes": it automatically chooses a handful of entry nodes and sticks with them for all circuits. This idea is adapted from the "helper node" concept published by Wright et al [4], but with improved reliability: rather than picking a set of entry nodes and refusing to access the Tor network if they all become unreachable, Tor's design dynamically picks new guards as needed, yet switches back to the old ones when they become reachable again. Therefore Tor users still have the same level of robustness as before, but the chance of a successful attack by a limited adversary is greatly reduced." Bumping the 0.1.0.16 ebuild should work just fine.
3) Stick with Tor 0.1.0.16 and manually configure a half dozen EntryNodes. See the FAQ entry [3] for some hints about how to do this. [3] http://wiki.noreply.org/noreply/TheOnionRouter/TorFAQ#ChooseEntryExit Maybe a resquest to all arches to mark 1.0.16 stable and adding a warning to the ebuild to see the fak, and then a GLSA with this information. As i dont think that bumping to alpha code a package that is already stable is a good idea.
I guess we'll issue a tempglas pending stable fixed release.
No tempglsa for a B4. I'd just wait for a stable release, setting it to [upstream]...
Still nothing upstream.
0.1.0.17 is released, but I'm not sure it fixes the issue. Humpback?
0.1.0.17 doesn't contain the fix AFAICT.
This is still only fixed in testing releases.
0.1.1.20 released as stable. Contains entry guards so fixes this.
humpback, please bump tor (bis)
handling the stabilization in bug #134329
to be closed : (common) [glsa]
GLSA 200606-04
