| Age | Commit message (Collapse) | Author |
|---|
|
|
|
This is a big-ish patch, but it's very straightforward. Under this
clang warning, we're not actually allowed to have a global variable
without a previous extern declaration for it. The cases where we
violated this rule fall into three roughly equal groups:
* Stuff that should have been static.
* Stuff that was global but where the extern was local to some
other C file.
* Stuff that was only global when built for the unit tests, that
needed a conditional extern in the headers.
The first two were IMO genuine problems; the last is a wart of how
we build tests.
|
|
This warning, IIUC, means that the compiler doesn't like it when it
sees a NULL check _after_ we've already dereferenced the
variable. In such cases, it considers itself free to eliminate the
NULL check.
There are a couple of tricky cases:
One was the case related to the fact that tor_addr_to_in6() can
return NULL if it gets a non-AF_INET6 address. The fix was to
create a variant which asserts on the address type, and never
returns NULL.
|
|
So, back long ago, XXX012 meant, "before Tor 0.1.2 is released, we
had better revisit this comment and fix it!"
But we have a huge pile of such comments accumulated for a large
number of released versions! Not cool.
So, here's what I tried to do:
* 0.2.9 and 0.2.8 are retained, since those are not yet released.
* XXX+ or XXX++ or XXX++++ or whatever means, "This one looks
quite important!"
* The others, after one-by-one examination, are downgraded to
plain old XXX. Which doesn't mean they aren't a problem -- just
that they cannot possibly be a release-blocking problem.
|
|
|
|
|
|
|
|
Patch from icanhasaccount; closes 18462.
|
|
|
|
Make it clearer that they are about outgoing connection attempts.
Specify the options involved where they were missing from one log
message.
Clarify a comment.
|
|
Downgrade logs and backtraces about IP versions to
info-level. Only log backtraces once each time tor runs.
Assists in diagnosing bug 18351; bugfix on c3cc8e16e in
tor-0.2.8.1-alpha.
Reported by "sysrqb" and "Christian", patch by "teor".
|
|
|
|
I didn't want to grant blanket permissions for chmod() and chown(),
so here's what I had to do:
* Grant open() on all parent directories of a unix socket
* Write code to allow chmod() and chown() on a given file only.
* Grant chmod() and chown() on the unix socket.
|
|
This is a part of a fix for 18253; bugfix on 0.2.8.1-alpha.
Alternatively, we could permit chmod/chown in the sandbox, but I
really don't like giving the sandbox permission to alter
permissions.
|
|
|
|
|
|
|
|
|
|
If there is a node, use node_ipv6_or/dir_preferred().
If there is no node, use fascist_firewall_prefer_ipv6_or/dirport().
|
|
|
|
|
|
|
|
|
|
If unix socket was configured as listener (such as a ControlSocket or a
SocksPort unix socket), and tor was started as root but not configured
to switch to another user, tor would segfault while trying to string
compare a NULL value. Fixes bug 18261; bugfix on 0.2.8.1-alpha. Patch
by weasel.
|
|
Conflicts:
src/or/directory.c
src/test/test_routerlist.c
Fix minor conflicts.
|
|
|
|
Bridge clients ignore ClientUseIPv6, acting as if it is always 1.
This preserves existing behaviour.
Make ClientPreferIPv6OR/DirPort auto by default:
* Bridge clients prefer IPv6 by default.
* Other clients prefer IPv4 by default.
This preserves existing behaviour.
|
|
|
|
Add unit tests, refactor pick_directory functions.
|
|
ClientUseIPv4 0 tells tor to avoid IPv4 client connections.
ClientPreferIPv6DirPort 1 tells tor to prefer IPv6 directory connections.
Refactor policy for IPv4/IPv6 preferences.
Fix a bug where node->ipv6_preferred could become stale if
ClientPreferIPv6ORPort was changed after the consensus was loaded.
Update documentation, existing code, add unit tests.
|
|
Avoid using a pronoun where it makes comments unclear.
Avoid using gender for things that don't have it.
Avoid assigning gender to people unnecessarily.
|
|
Avoid using gender for things that don't have it.
Avoid assigning a gender to tor users.
|
|
|
|
The Tor code base already contains usage of setsockopt(2) with an int as
their option value without problems.
|
|
According to the POSIX standard the option value is a pointer to void
and the option length a socklen_t. The Windows implementation makes the
option value be a pointer to character and the option length an int.
Casting the option value to a pointer to void conforms to the POSIX
standard while the implicit cast to a pointer to character conforms to
the Windows implementation.
The casts of the option length to the socklen_t data type conforms to
the POSIX standard. The socklen_t data type is actually an alias of an
int so it also conforms to the Windows implementation.
|
|
This might also be what #17752 needs.
|
|
|
|
|
|
|
|
|
|
|
|
connection_get_by_type_addr_port_purpose also ignores connections
that are marked for close.
|
|
port is in host order (addr is tor_addr_t, endianness is abstracted).
addr and port can be different to conn->addr and conn->port if
connecting via a proxy.
|
|
|
|
|
|
Doing this is no longer necessary, and it leads to weird recursions in
our call graph. Closes ticket 16480.
|
|
|
|
|
|
Fixes #16288
Signed-off-by: David Goulet <dgoulet@ev0ke.net>
|
|
|
