[tor-bugs] #4044 [Orbot]: Orbot release that includes 0.2.2.x stable?
Tor Bug Tracker & Wiki
torproject-admin at torproject.org
Sun Sep 18 16:22:51 UTC 2011
#4044: Orbot release that includes 0.2.2.x stable?
--------------------+-------------------------------------------------------
Reporter: arma | Owner: n8fr8
Type: task | Status: new
Priority: normal | Milestone:
Component: Orbot | Version:
Keywords: | Parent:
Points: | Actualpoints:
--------------------+-------------------------------------------------------
I notice that the last orbot release uses Tor 0.2.2.25-alpha.
Here are some major fixes since then that your users might like:
{{{
- Use the same circuit timeout for client-side introduction
circuits as for other four-hop circuits, rather than the timeout
for single-hop directory-fetch circuits; the shorter timeout may
have been appropriate with the static circuit build timeout in
0.2.1.x and earlier, but caused many hidden service access attempts
to fail with the adaptive CBT introduced in 0.2.2.2-alpha. Bugfix
on 0.2.2.2-alpha; fixes another part of bug 1297.
- In ticket 2511 we fixed a case where you could use an unconfigured
bridge if you had configured it as a bridge the last time you ran
Tor. Now fix another edge case: if you had configured it as a bridge
but then switched to a different bridge via the controller, you
would still be willing to use the old one. Bugfix on 0.2.0.1-alpha;
fixes bug 3321.
- When the controller configures a new bridge, don't wait 10 to 60
seconds before trying to fetch its descriptor. Bugfix on
0.2.0.3-alpha; fixes bug 3198 (suggested by 2355).
- Replace all potentially sensitive memory comparison operations
with versions whose runtime does not depend on the data being
compared. This will help resist a class of attacks where an
adversary can use variations in timing information to learn
sensitive data. Fix for one case of bug 3122. (Safe memcmp
implementation by Robert Ransom based partially on code by DJB.)
- When receiving a hidden service descriptor, check that it is for
the hidden service we wanted. Previously, Tor would store any
hidden service descriptors that a directory gave it, whether it
wanted them or not. This wouldn't have let an attacker impersonate
a hidden service, but it did let directories pre-seed a client
with descriptors that it didn't want. Bugfix on 0.0.6.
}}}
--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/4044>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online
More information about the tor-bugs
mailing list