Skip to content

GitLab

  • Projects
  • Groups
  • Snippets
  • Help
    • Loading...
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
    • Contribute to GitLab
  • Sign in
Trac
Trac
  • Project overview
    • Project overview
    • Details
    • Activity
  • Issues 246
    • Issues 246
    • List
    • Boards
    • Labels
    • Service Desk
    • Milestones
  • Operations
    • Operations
    • Metrics
    • Incidents
  • Analytics
    • Analytics
    • Value Stream
  • Wiki
    • Wiki
  • Members
    • Members
  • Collapse sidebar
  • Activity
  • Create a new issue
  • Issue Boards

GitLab is used only for code review, issue tracking and project management. Canonical locations for source code are still https://gitweb.torproject.org/ https://git.torproject.org/ and git-rw.torproject.org.

  • Legacy
  • TracTrac
  • Issues
  • #4044

Closed
Open
Opened Sep 18, 2011 by Roger Dingledine@arma

Orbot release that includes 0.2.2.x stable?

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.
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
None
Milestone
None
Assign milestone
Time tracking
None
Due date
None
Reference: legacy/trac#4044