| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
I think that the trailing __ got added in false analogy to
HAVE_MACRO__func__, HAVE_MACRO__FUNC__, and HAVE_MACRO__FUNCTION__.
But those macros actually indicate the presence of __func__,
__FUNC__, and __FUNCTION__ respectively. The __ at the end of
HAVE_EXTERN_ENVIRON_DECLARED would only be appropriate if the
environ were declared__, whatever that means.
(As a side-note, HAVE_MACRO__func__ and so on should probably be
renamed HAVE_MACRO___func__ and so on. But that can wait.)
This is an identifier renaming only.
|
| |
|
|
|
|
|
|
|
| |
We'd had our configure.in test include unistd.h unconditionally,
which would fail on Windows/mingw, even though environ _was_
declared there. Fix for 5704; bugfix on 0.2.3.13-alpha.
Thanks to Erinn for finding this and rransom for figuring out the
problem.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
They boil down to:
- MS_WINDOWS is dead and replaced with _WIN32, but we let a few
instances creep in when we merged Esteban's tests.
- Capitalizing windows header names confuses mingw.
- #ifdef 0 ain't C.
- One unit test wasn't compiled on windows, but was being listed
anyway.
- One unit test was checking for the wrong value.
Gisle Vanem found and fixed the latter 3 issues.
|
| |\ |
|
| | |
| |
| |
| | |
fixes bug 5623.
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is ticket 2479. Roger's original explanation was:
We have a series of bugs where relays publish a descriptor within
12 hours of their last descriptor, but the authorities drop it
because it's not different "enough" from the last one and it's
too close to the last one.
The original goal of this idea was to a) reduce the number of new
descriptors authorities accept (and thus have to store) and b)
reduce the total number of descriptors that clients and mirrors
fetch. It's a defense against bugs where relays publish a new
descriptor every minute.
Now that we're putting out one consensus per hour, we're doing
better at the total damage that can be caused by 'b'.
There are broader-scale design changes that would help here, and
we've had a trac entry open for years about how relays should
recognize that they're not in the consensus, or recognize when
their publish failed, and republish sooner.
In the mean time, I think we should change some of the parameters
to make the problem less painful.
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Previously we'd been using "we have clock_gettime()" as a proxy for
"we need -lrt to link a static libevent". But that's not really
accurate: we should only add -lrt if searching for clock_gettime
function adds -lrt to our libraries.
|
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Closes ticket 4572.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Fixes bug #4528 "read_to_buf_tls(): Inconsistency in code".
This check was added back in 0.1.0.3-rc, but somehow we forgot to
leave it in when we refactored read_to_buf_tls in 0.1.0.5-rc.
(patch by Arturo; commit message and changes file by nickm)
|
| |\ \ \ \ \ |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Instead of checking for 'rejected' and calling everything else okay,
let's check for 'outdated' and call everythign else a problem. This
way we don't risk missing future errors so much.
When logging a message that _looks_ like an error message at info, we
should mention that it isn't really a problem.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Specifically, it was a fix on 33e2053ebca5d, where we introduced the
WRA_* and ROUTER_* codes for dirserv_add_descriptor. Previously, we
had checked for a _negative_ return from dirserv_add_descriptor, which
meant "rejected". An insufficiently new descriptor would give a
0-valued return. But when we switched from numbers to enums, we got
this check wrong and had init_keys() give an error whenever the
descriptor wasn't accepted.
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Since 0.2.3.1-alpha, we've supported the Linux extensions to socket(),
open(), socketpair(), and accept() that enable us to create an fd and
make it close-on-exec with a single syscall. This not only saves us a
syscall (big deal), but makes us less vulnerable to race conditions
where we open a socket and then exec before we can make it
close-on-exec.
But these extensions are not supported on all Linuxes: They were added
between 2.6.23 or so and 2.6.28 or so. If you were to build your Tor
against a recent Linux's kernel headers, and then run it with a older
kernel, you would find yourselve unable to open sockets. Ouch!
The solution here is that, when one of these syscalls fails with
EINVAL, we should try again in the portable way. This adds an extra
syscall in the case where we built with new headers and are running
with old ones, but it will at least allow Tor to work.
Fixes bug 5112; bugfix on 0.2.3.1-alpha.
|
| |\ \ \ \ \ \ \ |
|
| | | |_|_|_|/ /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This fixes client_check_address_changed to work better with IPv6 Tor
clients, and prevents them from spewing errors. Fix for ticket 5537.
|
| | | | | | | | |
|
| | |_|_|_|_|/
|/| | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
The bump from miniupnpc-1.5 to 1.6 changes the definition of
two functions used by tor-fw-helper-upnp.c, upnpDiscover() and
UPNP_AddPortMapping(). This patch addresses this and adds a
check in configure.in for backwards compatibility.
Thanks to Nickolay Kolchin-Semyonov for some hints.
X-Tor-Bug-URL: https://trac.torproject.org/projects/tor/ticket/5434
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=376621
Signed-off-by: Anthony G. Basile <blueness@gentoo.org>
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \ |
|
| | |/ / / / /
| | | | | |
| | | | | |
| | | | | | |
Bug 5438.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Previously, we would reset it at the drop of a hat -- every time a second
passes without any of the intro-point circs already launched for the
service failing.
Fixes bug 4607.
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
In general, whenever we can, we should be doing
base64_decode(buf, sizeof(buf), s, strlen(s)),
and not
base_64_decode(buf, expr1, s, expr2)
where we hope that expr1 is a good name for the size of buf and expr2
is a good formula for the length of the base64 expression in s.
|
| | | | | | | | |
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
* Remove the ugly if statement.
* constify 'bridge_info_t' in SMARTLIST_FOREACH_BEGIN.
|
| | | |_|_|/ /
| |/| | | | |
|
| |\ \ \ \ \ \ |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix for 5647; bugfix on 0.2.1.5-alpha.
|
| | | | | | | | |
|
| |\| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Conflicts:
src/or/rendservice.c
Conflicts were due to new NON_ANONYMOUS_MODE_ENABLED tor2web code; I
think I resolved them correctly.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
(Cherry-picked from 6ba13e4 by nickm)
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fixes coverity CID 508: coverity scan doesn't like checking a
variable for non-NULL after it has been definitely dereferenced.
This should take us back down to zero coverity issues.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
Fix for 5635; fix on 0.2.2.26-beta, where caches stopped fetching this
information.
|
| | |/ / / / /
|/| | | | | |
|
| |\| | | | | |
|
| | |\ \ \ \ \ |
|