Karsten Loesing [Tue, 9 Nov 2010 13:18:00 +0000 (14:18 +0100)]
Turn on directory request statistics by default.
Change the default values for collecting directory request statistics and
inlcuding them in extra-info descriptors to 1.
Don't break if we are configured to collect directory request or entry
statistics and don't have a GeoIP database. Instead, print out a notice
and skip initializing the affected statistics code.
Nick Mathewson [Fri, 2 Sep 2011 15:51:49 +0000 (11:51 -0400)]
Look for correct "ar" to cross-compile
For some reason, autoconf doesn't by default have an "AC_PROG_AR" for
this -- possibly it's assumed that any "ar" you have will work
everyplace.
Fixes bug 3909; found by sid77.
This fixes a build issue first present in fdbdb4dc1500, but the bug
(of not using a correct ar) has been in every Tor version ever: it
just didn't matter until then.
Nick Mathewson [Wed, 31 Aug 2011 00:42:51 +0000 (20:42 -0400)]
Use %f with printf-style formatting, not %lf
For printf, %f and %lf are synonymous, since floats are promoted to
doubles when passed as varargs. It's only for scanf that we need to
say "%lf" for doubles and "%f" for floats.
Apparenly, some older compilers think it's naughty to say %lf and like
to spew warnings about it.
Sebastian Hahn [Wed, 10 Aug 2011 17:22:41 +0000 (19:22 +0200)]
Ignore deprecation warnings on OS X
Starting with Lion, Apple decided to deprecate the system openssl. We
can start requiring users to install their own openssl once OS X doesn't
ship with it anymore.
Nick Mathewson [Wed, 20 Jul 2011 17:16:06 +0000 (13:16 -0400)]
Check return value in fmt_addr
Previously, if tor_addr_to_str() returned NULL, we would reuse the
last value returned by fmt_addr(). (This could happen if we were
erroneously asked to format an AF_UNSPEC address.) Now instead we
return "???".
Sebastian Hahn [Thu, 7 Jul 2011 03:27:20 +0000 (05:27 +0200)]
Correctly send a SUCCEEDED event for rdns requests
The issue was that we overlooked the possibility of reverse DNS success
at the end of connection_ap_handshake_socks_resolved(). Issue discovered
by katmagic, thanks!
Nick Mathewson [Fri, 1 Jul 2011 16:14:44 +0000 (12:14 -0400)]
Use strlcpy when copying node IDs into measured_bw_line_t
We were using strncpy before, which isn't our style for stuff like
this.
This isn't a bug, though: before calling strncpy, we were checking
that strlen(src) was indeed == HEX_DIGEST_LEN, which is less than
sizeof(dst), so there was no way we could fail to NUL-terminate.
Still, strncpy(a,b,sizeof(a)) is an idiom that we ought to squash
everyplace.
Nick Mathewson [Fri, 1 Jul 2011 16:06:54 +0000 (12:06 -0400)]
Use strlcpy in create_unix_sockaddr()
Using strncpy meant that if listenaddress were ever >=
sizeof(sockaddr_un.sun_path), we would fail to nul-terminate
sun_path. This isn't a big deal: we never read sun_path, and the
kernel is smart enough to reject the sockaddr_un if it isn't
nul-terminated. Nonetheless, it's a dumb failure mode. Instead, we
should reject addresses that don't fit in sockaddr_un.sun_path.
Coverity found this; it's CID 428. Bugfix on 0.2.0.3-alpha.
Roger Dingledine [Fri, 17 Jun 2011 07:31:59 +0000 (03:31 -0400)]
log when we finish ssl handshake and move to renegotiation
debug-level since it will be quite common. logged at both client
and server side. this step should help us track what's going on
with people filtering tor connections by our ssl habits.
Jérémy Bobbio [Tue, 14 Jun 2011 16:18:32 +0000 (12:18 -0400)]
Make ControlSocketsGroupWritable work with User.
Original message from bug3393:
check_private_dir() to ensure that ControlSocketsGroupWritable is
safe to use. Unfortunately, check_private_dir() only checks against
the currently running user… which can be root until privileges are
dropped to the user and group configured by the User config option.
The attached patch fixes the issue by adding a new effective_user
argument to check_private_dir() and updating the callers. It might
not be the best way to fix the issue, but it did in my tests.
Nick Mathewson [Wed, 1 Jun 2011 15:48:39 +0000 (11:48 -0400)]
Check maximum properly in crypto_rand_int()
George Kadianakis notes that if you give crypto_rand_int() a value
above INT_MAX, it can return a negative number, which is not what
the documentation would imply.
The simple solution is to assert that the input is in [1,INT_MAX+1].
If in the future we need a random-value function that can return
values up to UINT_MAX, we can add one.