- Dec 17, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Roger Dingledine authored
-
- Dec 16, 2010
-
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Roger Dingledine authored
-
Nick Mathewson authored
-
Karsten Loesing authored
-
Nick Mathewson authored
Conflicts: src/common/memarea.c src/or/or.h src/or/rendclient.c
-
Nick Mathewson authored
-
Nick Mathewson authored
This will avoid some signed/unsigned assignment-related bugs.
-
- Dec 14, 2010
-
-
Nick Mathewson authored
Conflicts: src/config/geoip
-
- Dec 13, 2010
-
-
Nick Mathewson authored
It's all too easy in C to convert an unsigned value to a signed one, which will (on all modern computers) give you a huge signed value. If you have a size_t value of size greater than SSIZE_T_MAX, that is way likelier to be an underflow than it is to be an actual request for more than 2gb of memory in one go. (There's nothing in Tor that should be trying to allocate >2gb chunks.)
-
Nick Mathewson authored
-
- Dec 08, 2010
-
-
Karsten Loesing authored
-
- Dec 07, 2010
-
-
Nick Mathewson authored
-
Nick Mathewson authored
This was the first version to cache the correct directory information. Fixes bug 2156.
-
Nick Mathewson authored
-
- Dec 06, 2010
-
-
Nick Mathewson authored
If you had TIME_MAX > INT_MAX, and your "time_to_exhaust_bw = accountingmax/expected_bandwidth_usage * 60" calculation managed to overflow INT_MAX, then your time_to_consider value could underflow and wind up being rediculously low or high. "Low" was no problem; negative values got caught by the (time_to_consider <= 0) check. "High", however, would get you a wakeup time somewhere in the distant future. The fix is to check for time_to_exhaust_bw overflowing INT_MAX, not TIME_MAX: We don't allow any accounting interval longer than a month, so if time_to_exhaust_bw is significantly larger than 31*24*60*60, we can just clip it. This is a bugfix on 0.0.9pre6, when accounting was first introduced. It fixes bug 2146, unless there are other causes there too. The fix is from boboper. (I tweaked it slightly by removing an assignment that boboper marked as dead, and lowering a variable that no longer needed to be function-scoped.)
-
Nick Mathewson authored
The old logic would have us fetch from authorities if we were refusing unknown exits and our exit policy was reject*. Instead, we want to fetch from authorities if we're refusing unknown exits and our exit policy is _NOT_ reject*. Fixed by boboper. Fixes more of 2097. Bugfix on 0.2.2.16-alpha.
-
- Dec 03, 2010
-
-
Nick Mathewson authored
We use a hash of the identity key to seed a prng to tell when an accounting period should end. But thanks to the bug998 changes, clients no longer have server-identity keys to use as a long-term seed in accounting calculations. In any case, their identity keys (as used in TLS) were never never fixed. So we can just set the wakeup time from a random seed instead there. Still open is whether everybody should be random. This patch fixes bug 2235, which was introduced in 0.2.2.18-alpha. Diagnosed with help from boboper on irc.
-
- Dec 02, 2010
-
-
Nick Mathewson authored
Bugfix on 0.1.1.1-alpha; found by boboper.
-
- Dec 01, 2010
-
-
Specified grammars for orconn-status and entry-guards for Tor versions 0.1.2.2-alpha through 0.2.2.1-alpha with feature VERBOSE_NAMES turned off.
-
The spec stated that support for the helper-nodes command would be removed in 0.1.3.x, however support for this command is still in Tor. Updated the spec to reflect this and added a node that the command is deprecated.
-
Several updates to grammars for events and GETINFO results. All relate to the fact that LongName has replaced ServerID since 0.2.2.1-alpha. See documentation of VERBOSE_NAMES for more information. The following grammars were changed: * orconn-status GETINFO result * entry-guards GETINFO result * Path general token * OR Connection status changed event * New descriptors available event In all cases a note was added about when the old grammar applies.
-
(1) Made the wording of the comments consistant with token names. Digest/Fingerprint and Name/Nickname were being used interchangeably. Better to just use Fingerprint and Nickname becuase they are the names of the tokens. (2) Places the tokens currently in use before the tokens used in older versions. ServerSpec should be documented before ServerID. (3) Added a note to the comments about ServerID that cross reference the VERBOSE_FEATURE, allowing users to see when and why ServerID was replaced with LongName.
-
(1) On by default is a bad way to describe features. Rather, they are always on and should be viewed as a part of the control protocol. Updated the wording in USEFEATURE to reflect this. (2) Made descriptions of Tor versions consistant across all features. There is the version in which a feature was introduced and the version in which it became part of the protocol. (3) Reworded the description of the VERBOSE_NAMES feature. The previous wording describes the way things used to be first. Better to lead with the current state of things and then describe how it differs from old versions.
-
Roger Dingledine authored
Conflicts: doc/Makefile.am
-
Roger Dingledine authored
-
Nick Mathewson authored
-
- Nov 29, 2010
-
-
Nick Mathewson authored
Also add a changes file
-
Nick Mathewson authored
On windows, it's called something different.
-
Nick Mathewson authored
-
The reason the "streams problem" occurs is due to the complicated interaction between Tor's congestion control and libevent. At some point during the experiment, the circuit window is exhausted, which blocks all edge streams. When a circuit level sendme is received at Exit, it resumes edge reading by looping over linked list of edge streams, and calling connection_start_reading() to inform libevent to resume reading. When the streams are activated again, Tor gets the chance to service the first three streams activated before the circuit window is exhausted again, which causes all streams to be blocked again. As an experiment, we reversed the order in which the streams are activated, and indeed the first three streams, rather than the last three, got service, while the others starved. Our solution is to change the order in which streams are activated. We choose a random edge connection from the linked list, and then we activate streams starting from that chosen stream. When we reach the end of the list, then we continue from the head of the list until our chosen stream (treating the linked list as a circular linked list). It would probably be better to actually remember which streams have received service recently, but this way is simple and effective.
-
Nick Mathewson authored
-
Nick Mathewson authored
-
- Nov 24, 2010
-
-
Nick Mathewson authored
-
Robert Ransom authored
Reported by an anonymous commenter on Trac.
-