| Commit message (Collapse) | Author | Age |
|
|
|
| |
Fix for #10470 as suggested by arma
|
|
|
|
|
|
|
| |
We renamed the option, but we didn't actually fix it in the log
messages or the docs. This patch does that.
For #10124. Patch by sqrt2.
|
|\ |
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
According to the manpage, bridges use P256 for conformity and relays
use P224 for speed. But skruffy points out that we've gotten it
backwards in the code.
In this patch, we make the default P256 for everybody.
Fixes bug 9780; bugfix on 0.2.4.8-alpha.
|
|/
|
|
|
|
|
|
|
|
|
| |
Explicitly include bridges, and note that we archive and publish all
descriptors.
(We are not yet publishing ContactInfo lines contained in bridge
descriptors, but maybe we'll want to do that soon, so let's err on the
side of caution here.)
Related to #9854.
|
| |
|
|
|
|
|
|
|
|
| |
For now, round down to the nearest 10 minutes. Later, eliminate entirely by
setting a consensus parameter.
(This rounding is safe because, in 0.2.2, where the timestamp mattered,
REND_REPLAY_TIME_INTERVAL was a nice generous 60 minutes.)
|
| |
|
| |
|
|
|
|
|
| |
Now a user who changes only NumEntryGuards will get the behavior she
expects. Fixes bug 9354; bugfix on 0.2.4.8-alpha.
|
| |
|
|\
| |
| |
| |
| |
| | |
Conflicts:
src/or/config.c
src/or/relay.c
|
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This implements "algorithm 1" from my discussion of bug #9072: on OOM,
find the circuits with the longest queues, and kill them. It's also a
fix for #9063 -- without the side-effects of bug #9072.
The memory bounds aren't perfect here, and you need to be sure to
allow some slack for the rest of Tor's usage.
This isn't a perfect fix; the rest of the solutions I describe on
codeable.
|
| | |
|
| |
| |
| |
| | |
Spotted on tor-talk by "hamahangi".
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
doc/tor.1.txt
src/or/config.c
src/or/connection.c
|
| |/
| |
| |
| |
| |
| | |
This might be necessary if the bug8117 fix confuses any applications.
Also add a changes file.
|
| | |
|
| | |
|
| |
| |
| |
| |
| | |
This adds a new option to fix bug 8508 which broke chutney
networks. The bug was introduced by 317d16de.
|
|\ \
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Conflicts:
doc/tor.1.txt
src/or/circuitbuild.c
src/or/config.c
src/or/or.h
|
| | |
| | |
| | |
| | |
| | | |
Mike believes that raising the default to 2 months with no way to lower
it may create horrible load-balancing issues.
|
| | | |
|
| |/
| |
| |
| |
| |
| |
| | |
Fixes 8240.
(Don't actually increase the default guard lifetime. It seems likely to
break too many things if done precipitiously.)
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
Now the manpages no longer refer to tsocks or tsocks.conf, and we no
longer have or ship a tor-tsocks.conf. The only remaining instances
of "tsocks" in our repository are old ChangeLog and ReleaseNotes
entries, and the torify script saying that it doesn't support tsocks.
Fixes bug 8290.
|
|/ /
| |
| |
| | |
resolves ticket 8443.
|
| |
| |
| |
| | |
Fixes bug 7876
|
| | |
|
|\ \ |
|
| | |
| | |
| | |
| | |
| | |
| | | |
(for various values of K), to further reduce confusion about whether
Tor counts in units of memory or fractions of units of memory. Fixes
bug 7054.
|
| | | |
|
|\ \ \ |
|
| | | | |
|
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
This is ticket 7706, reported by "bugcatcher." The rationale here
is that if somebody says 'ExcludeNodes {tv}', then they probably
don't just want to block definitely Tuvaluan nodes: they also want
to block nodes that have unknown country, since for all they know
such nodes are also in Tuvalu.
This behavior is controlled by a new GeoIPExcludeUnknown autobool
option. With the default (auto) setting, we exclude ?? and A1 if
any country is excluded. If the option is 1, we add ?? and A1
unconditionally; if the option is 0, we never add them.
(Right now our geoip file doesn't actually seem to include A1: I'm
including it here in case it comes back.)
This feature only takes effect if you have a GeoIP file. Otherwise
you'd be excluding every node.
|
| | | |
| | | |
| | | |
| | | |
| | | | |
Also, deprecate the torrc options for the scaling values. It's unlikely anyone
but developers will ever tweak them, even if we provided a single ratio value.
|
|\ \ \ \ |
|
| |/ / /
| | | |
| | | |
| | | |
| | | |
| | | | |
Instead of hardcoding the minimum fraction of possible paths to 0.6, we
take it from the user, and failing that from the consensus, and
failing that we fall back to 0.6.
|
|\ \ \ \ |
|
| |/ / / |
|
|/ / /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
The right way to set "MaxOnionsPending" was to adjust it until the
processing delay was appropriate. So instead, let's measure how long
it takes to process onionskins (sampling them once we have a big
number), and then limit the queue based on its expected time to
finish.
This change is extra-necessary for ntor, since there is no longer a
reasonable way to set MaxOnionsPending without knowing what mix of
onionskins you'll get.
This patch also reserves 1/3 of the onionskin spots for ntor
handshakes, on the theory that TAP handshakes shouldn't be allowed to
starve their speedier cousins. We can change this later if need be.
Resolves 7291.
|
|\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Conflicts:
src/or/cpuworker.c
src/or/or.h
src/test/bench.c
|
| | | | |
|
|\ \ \ \ |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | | |
|
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
With an IPv6 virtual address map, we can basically hand out a new
IPv6 address for _every_ address we connect to. That'll be cool, and
will let us maybe get around prop205 issues.
This uses some fancy logic to try to make the code paths in the ipv4
and the ipv6 case as close as possible, and moves to randomly
generated addresses so we don't need to maintain those stupid counters
that will collide if Tor restarts but apps don't.
Also has some XXXX items to fix to make this useful. More design
needed.
|