[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

[tor-bugs] #4044 [Orbot]: Orbot release that includes 0.2.2.x stable?



#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs