| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
| |
since router_parse_entry_from_string() already checks whether
!tor_inet_aton(router->address, &in)
(And no need to print address, since router_describe does that.)
|
| |
|
|
|
|
| |
To avoid surprises, good coding practice suggests parenthesizing every
macro definition -- or at the very least, all those involving an
expression.
|
| |\ |
|
| | |
| |
| |
| | |
Fixes bug 7727; fix on 0.2.4.10-alpha.
|
| |\ \ |
|
| | | | |
|
| |\ \ \
| |/ /
|/| | |
|
| | |\ \ |
|
| | | | | |
|
| |\ \ \ \
| |_|_|/
|/| | |
| | | |
| | | | |
Conflicts:
src/or/connection.c
|
| | | | | |
|
| | | | | |
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
Conflicts:
src/common/util.c
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Spotted by coverity, bug 7816, bugfix on various versions.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes part of 7816. Spotted by coverity. Fix on 0.2.2.1-alpha.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Coverity spotted this. Bug 7816. Fix on 0.2.3.13-alpha.
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Spotted by coverity; partial fix for 7816; bugfix on 0.2.0.5-alpha.
|
| | | |/ / /
| |/| | |
| | | | |
| | | | |
| | | | | |
This one hits if the snprintf() fails when we're writing our IPv6
exit policy. It's new in 0.2.4.7-alpha. Part of bug 7816.
|
| |\ \ \ \ \ |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Bug 7902; fix on 0.1.0.1-rc.
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I think we want both sets of messages to appear independently to help us know
what needs tuning.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
I noticed bad wifi networks can have low use success rates.
|
| |\ \ \ \ \ \ \ |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Right now, all our curve25519 backends ignore the high bit of the
public key. But possibly, others could treat the high bit of the
public key as encoding out-of-bounds values, or as something to be
preserved. This could be used to distinguish clients with different
backends, at the cost of killing a circuit.
As a workaround, let's just clear the high bit of each public key
indiscriminately before we use it. Fix for bug 8121, reported by
rransom. Bugfix on 0.2.4.8-alpha.
|
| |\ \ \ \ \ \ \ \
| |_|/ / / / / /
|/| | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Implements ticket 8151.
|
| | | | | | | | | |
|
| |/ / / / / / / |
|
| |\ \ \ \ \ \ \ |
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Authorities don't set is_possible_guard on node_t, so they were
never deciding that they could build enough paths. This is a quick
and dirty fix.
Bug not in any released version of Tor
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This prevents bug 8147, where such nodes would accrue points towards
Guard, Fast, HSDir, and so on.
Fixes bug 8147.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Another bug 8145 fix.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix for 8145.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixes bug 8146.
|
| |\ \ \ \ \ \ \ |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
It appears that the code for 7291 gave an unused-value warning when
built with --disable-curve25519.
|
| | |/ / / / / /
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The fix is to move the two functions to format/parse base64
curve25519 public keys into a new "crypto_format.c" file. I could
have put them in crypto.c, but that's a big file worth splitting
anyway.
Fixes bug 8153; bugfix on 0.2.4.8-alpha where I did the fix for 7869.
|
| |/ / / / / /
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
These seem to have gotten conflicted out of existence while mike was
working on path bias stuff.
Thanks to sysrqb for collecting these in a handy patch.
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| |\ \ \ \ \ \ \ |
|