Now that the pt code logs mp->argv[0] all over the place, we need to
be sure to set up mp->argv in our tests.
Bugfix on e603692adc, not in any released version.
If the authorities agreed on a sufficiently bad bwweightscale value
(<=0 or == INT32_MAX), the bandwidth algorithm could make the voters
assert while computing the consensus.
Fix for bug5786; bugfix on 0.2.2.17-alpha
The underlying strtoX functions handle overflow by saturating and
setting errno to ERANGE. If the min/max arguments to the
tor_parse_* functions are equal to the minimum/maximum of the
underlying type, then with the old approach, we wouldn't treat a
too-large value as genuinely broken.
Found this while looking at bug 5786; bugfix on 19da1f36 (in Tor
0.0.9), which introduced these functions.
(Note: It makes sense to use tor-gencert on Windows for testing
purposes only. If you are a directory authority operator, and you
are contemplating running tor-gencert on a Windows box in an actual
production environment, you are probably making a mistake.)
We had been checking for EINVAL, but that means that SOCK_* isn't
supported, not that the syscall itself is missing.
Bugfix on 0.2.3.1-alpha, which started to use accept4.
This is how IPv6 says "0.0.0.0" and something we will have to
translate into a globally reachable address before putting it in a
descriptor.
The fix is a short term solution until a real one is implemented.
Closes#5146.
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.
If the client uses a v2 cipherlist on the renegotiation handshake,
it looks as if they could fail to get a good cert chain from the
server, since they server would re-disable certificate chaining.
This patch makes it so the code that make the server side of the
first v2 handshake special can get called only once.
Fix for 4591; bugfix on 0.2.0.20-rc.
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 #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.
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>
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.
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.
* Document fmt_addr_impl() and friends.
* Parenthesize macro arguments.
* Rename get_first_listener_addrport_for_pt() to
get_first_listener_addrport_string().
* Handle port_cfg_t with no_listen.
* Handle failure of router_get_active_listener_port_by_type().
* Add an XXX to router_get_active_listener_port_by_type().
This is just refactoring work here. The old logic was kind of
convoluted, especially after the bug 5572 fix. We don't actually need to
distinguish so many cases here. Dropping detection of the
"!old_options || !old_options->DynamicDHGroups" case is fine because
that's the same that we'd do for clients.
Also add a changes file for bug 5572.
The message only means that we're publishing a new descriptor when we
are actually in some kind of server mode, and publication is on.
Fix for bug 3942; bugfix on 0.2.3.2-alpha.
This fixes a side-channel attack on the (fortunately unused!)
BridgePassword option for bridge authorities. Fix for bug 5543;
bugfix on 0.2.0.14-alpha.
Introduce get_first_listener_addrport_for_pt() which returns a string
containing the addrport of the first listener we could find. Use it to
form the TOR_PT_ORPORT managed proxy protocol line.
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.
When we started RefuseUnknownExits back in 0.2.2.11-alpha, we
started making exits act like they cache directory info (since they
need an up-to-date idea of who is really a router). But this
included fetching needless (unrecognized) authorities' certs, which
doesn't make any sense for them.
This is related to, but not necessarily the same as, the issue that
Ian reported for bug #2297.
(This patch is based on a patch from a user who I believe has asked
not to be named. If I'm wrong about that, please add the
appropriate name onto the changelog.)
==
Nick here. I tweaked this patch a little to make it apply cleanly to
master, to extract some common code into a function, and to replace
snprintf with tor_snprintf.
-- nickm
One of our unit tests checks that they behave correctly (giving an
error) when the base is negative. But there isn't a guarantee that
strtol and friends actually handle negative bases correctly.
Found by Coverity Scan; fix for CID 504.
Coverity doesn't like the fact that we were storing the value of
parse_config_line_from_str() but not checking it in a couple of
cases.
Fixes CID 505 and 506.
Calling crypto_cipher_free(NULL) is always safe, since (by
convention) all of our xyz_free() functions treat xyz_free(NULL) as
a no-op.
Flagged by coverity scan; fixes CID 508 and 509.
A previous commit in the 5527 branch had moved
router_get_mutable_by_digest(digest_rcvd) to happen before we did
tor_assert(digest_rcvd), which would have defeated the purpose of
the assert.
Specifically, I believe it dates back to when extend cells had address:port
but no digest in them. The special edge case is certainly not worth the
complexity these days.
* This assertion fails when executing the whole suite, but not when executing
this test by itself
* Ideally I'd prefer starting with a guaranteed empty directory, but it's not
very important in this case as non-existence of other paths is being checked
explicitly
* Add several failing tests (embedded in an "#if 0" block) for behaviour that
doesn't match strtok_r
* Add another, passing, more interesting test
* Use test_eq_ptr(NULL, ...) instead of test_assert(NULL == ...)
* Add many new test cases, tweak/improve existing ones, reorganize them a bit
* Switch the parameters in all test_eq calls so the expected value is the first
* Change all the "r = tor_sscanf(...);\ntest_eq(1, r)" to the more compact
"test_eq(1, tor_sscanf(...))". It may be a tiny bit harder to find the
tor_sscanf calls (it's the long lines anyway), but it saves a lot of lines,
which should help readability.
* Switch some test_eq parameters so the expected is always the first parameter
* Drop some manual checks of compressed format magic numbers (they're pointless
and they make the unit tests less readable and more fragile, considering
we're already indirectly checking those magic numbers via the
detect_compression_method function)
* Add a couple of extra assertions
* The test currently fails, but it's commented out (with an "#if 0")
* As a broken octal actually gives a parse error, it seems fair that this
fails, too
This mitigates an attack proposed by wanoskarnet, in which all of a
client's bridges collude to restrict the exit nodes that the client
knows about. Fixes bug 5343.
In the distant past, connection_handle_read() could be called when there
are pending bytes in the TLS object during the main loop. The design
since then has been to always read all pending bytes immediately, so
read events only trigger when the socket actually has bytes to read.
Resolves bug 5324.
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.
There is a facility (not used now in Tor) to avoid storing the hash
of a given type if it is a fast-to-calculate hash.
There are also a few ancient-openbsd compilation issues fixed here.
The fact that Tor says INLINE while Libevent says inline remains
unaddressed.
The big change here is a patch (first added to Libevent by Ed Day)
to make sure that the CreateProcess forked-test trick works even
when the main test program is invoked without its .exe suffix.
The invariant is: unconfigured_proxies_n is exactly the number of
managed_proxy_t not in state PT_PROTO_COMPLETED.
To maintain this, we need to stop overloading unconfigured_proxies_n
to also count managed_proxy_t items that are in PT_PROTO_COMPLETED but
which might need relaunching. To make it so we can detect those, we
introduce another variable.
This commit also adds a function to assert that we haven't broken the
invariant.
Fix for bug 5084; bugfix on 0.2.3.6-alpha, I think.
In some cases, we solve this by doing a SMARTLIST_DEL_CURRENT before
calling managed_proxy_destroy. But for a trickier one, we just make a
copy of the list before iterating over it, so that changes to the
manage proxy list don't hurt our iteration.
This could be related to bug 5084.
in Makefile.am, we used it without quoting it, causing build failure if
your openssl/sed/sha1sum happened to live in a directory with a space in
it (very common on windows)
This reverts commit 55e8cae815.
The conversation from irc:
> weasel: i had intended to leave torrc.sample.in alone in maint-0.2.2,
since i don't want to make all your stable users have to deal with
a torrc change. but nickm changed it. is it in fact the case that a
change in that file means a change in the deb?
<weasel> it means you'll prompt every single user who ever touched
their torrc
<weasel> and they will be asked if they like your new version better
than what they have right now
<weasel> so it's not great
Instead I changed the website to redirect requests for the tor-manual
URL listed in maint-0.2.2's torrc.sample.in so the link will still work.
If we don't do this, [::] can be interpreted to mean all v4 and all
v6 addresses. Found by dcf. Fixes bug 4760. See RFC 3493 section
5.3 for more info.
There was one MS_WINDOWS that remained because it wasn't on a macro
line; a few remaining uses (and the definition!) in configure.in;
and a now-nonsensical stanza of eventdns_tor.h that previously
defined 'WIN32' if it didn't exist.
This commit is completely mechanical; I used this perl script to make it:
#!/usr/bin/perl -w -i.bak -p
if (/^\s*\#/) {
s/MS_WINDOWS/_WIN32/g;
s/\bWIN32\b/_WIN32/g;
}
Previously the client would ask the bridge for microdescriptors, which are
only supported in 0.2.3.x and later, and then fail to bootstrap when it
didn't get the answers it wanted. Fixes bug 4013; bugfix on 0.2.3.2-alpha.
The fix here is to revert to using normal descriptors if any of our
bridges are known to not support microdescs. This is not ideal, a) because
we'll start downloading a microdesc consensus as soon as we get a bridge
descriptor, and that will waste time if we later get a bridge descriptor
that tells us we don't like microdescriptors; and b) by changing our mind
we're leaking to our other bridges that we have an old-version bridge.
The alternate fix would have been to change
we_use_microdescriptors_for_circuits() to ask if *any* of our bridges
can support microdescriptors, and then change the directory logic that
picks a bridge to only select from those that do. For people living in
the future, where 0.2.2.x is obsolete, there won't be a difference.
Note that in either of these potential fixes, we have risk of oscillation
if our one funny-looking bridges goes away / comes back.
These were found by looking for tor_snprintf() instances that were
preceeded closely by tor_malloc(), though I probably converted some
more snprintfs as well.
(In every case, make sure that the length variable (if any) is
removed, renamed, or lowered, so that anything else that might have
assumed a longer buffer doesn't exist.)
These were found by looking for tor_snprintf() instances that were
followed closely by tor_strdup(), though I probably converted some
other snprintfs as well.
(To ensure correctness, in every case, make sure that the temporary
variable is deleted, renamed, or lowered in scope, so we can't have
any bugs related to accidentally relying on the no-longer-filled
variable.)
Fixes bug #4897, not yet in any release.
Using n_circ_id alone here (and below, when n_conn is NULL) really sucks,
but that's a separate bug which will need a changes/ file.
To solve bug 4779, we want to avoid OpenSSL 1.0.0's counter mode.
But Fedora (and maybe others) lie about the actual OpenSSL version,
so we can't trust the header to tell us if it's safe.
Instead, let's do a run-time test to see whether it's safe, and if
not, use our built-in version.
fermenthor contributed a pretty essential fixup to this patch. Thanks!
When we have an effective bandwidthrate configured so that we cannot
exceed our bandwidth limit in one accounting interval, don't disable
advertising the dirport. Implements ticket 2434.
MAX_DNS_LABEL_SIZE was only defined for old versions of openssl, which
broke the build. Spotted by xiando. Fixes bug 4413; not in any released
version.
The thing that's limited to 63 bytes is a "label", not a hostname.
Docment input constraints and behavior on bogus inputs.
Generally it's better to check for overflow-like conditions before
than after. In this case, it's not a true overflow, so we're okay,
but let's be consistent.
pedantic less->fewer in the documentation
Fixes bug 4413; bugfix on xxxx.
Hostname components cannot be larger than 63 characters.
This simple check makes certain randlen cannot overflow rand_bytes_len.
We used to do this as a workaround for older Tors, but now it's never
the correct thing to do (especially since anything that didn't
understand RELAY_EARLY is now deprecated hard).
This patch should make us reject every Tor that was vulnerable to
CVE-2011-0427. Additionally, it makes us reject every Tor that couldn't
handle RELAY_EARLY cells, which helps with proposal 110 (#4339).
Previously we required 1.0.0, but there was a bug in the 1.0.0 counter
mode. Found by Pascal. Fixes bug 4779.
A more elegant solution would be good here if somebody has time to code
one.
Back in #1240, r1eo linked to information about how this could happen
with older Linux kernels in response to nmap. Bugs #4545 and #4547
are about how our approach to trying to deal with this condition was
broken and stupid. Thanks to wanoskarnet for reminding us about #1240.
This is a fix for the abovementioned bugs, and is a bugfix on
0.1.0.3-rc.
Preprocessor directives should not be put inside the arguments
of a macro. This is not supported on older GCC releases (< 3.3)
thus broke compilation on Haiku (running gcc2).
