On Windows, getsockname() on a nonblocking apparently won't work
until the connection is done connecting. On XP, it seems to fail by
reporting success and declaring that your address is INADDR_ANY. On the
Win8 preview, though, it fails more loudly and says WSAEINVAL.
Fix for bug 5374; bugfix on 0.1.1.14-alpha.
Roger explains at
http://archives.seul.org/tor/talk/Nov-2011/msg00209.html :
"If you list your bridge as part of your family in the relay
descriptor, then everybody can learn your bridge fingerprint, and
they can look up your bridge's descriptor (and thus location) at
the bridge directory authority."
Now, we can't stop relays from listing bridges, but we can warn when
we notice a bridge listing anybody, which might help some.
This fixes bug 4657; it's a fix on 0.2.0.3-alpha, where bridges were
first introduced.
To hit this leak, you need to be a relay that gets a RESOLVE request
or an exit node getting a BEGIN or RESOLVE request. You must either
have unconfigured (and unconfigurable) nameservers, or you must have
somehow set DisableNetwork after a network request arrived but
before you managed to process it.
So, I doubt this is reached often. Still, a leak's a leak. Fix for
bug 5916; bugfix on 0.2.3.9-alpha and 0.1.2.1-alpha.
%f is correct; %lf is only needed with scanf. Apparently, on some
old BSDs, %lf is deprecated.
Didn't we do this before? Yes, we did. But we only got the
instances of %lf, not more complicated things like %.5lf . This
patch tries to get everything.
Based on a patch for 3894 by grarpamp.
These errors usually mean address exhaustion; reporting them as such
lets clients adjust their load to try other exits.
Fix for bug 4710; bugfix on 0.1.0.1-rc, which started using
END_STREAM_REASON_RESOURCELIMIT.
Silences the log message:
[warn] {BUG} _connection_mark_unattached_ap(): Bug: stream (marked at connection_edge.c:2224) sending two socks replies?
after the client triggered the "Tor is not an HTTP Proxy" response.
No additional socks reply was sent, though.
Previously, we only did this check at startup, which could lead to
us holding a guard indefinitely, and give weird results. Fixes bug
5380; bugfix on 0.2.1.14-rc.
(Patch by Roger; changes file and commit message by Nick)
Previously, we skipped everything that got invoked from
options_init_from_torrc. But some of the stuff in
options_act_reversible and options_act is actually important, like
reopening the logs.
Now, a SIGHUP always makes the effects of an options_set() happen,
even though the options haven't changed.
Fix for bug 5095; bugfix on 0.2.1.9-alpha, which introduced
__ReloadTorrcOnSIGHUP.
This would happen if the deliver window could become negative
because of an nonexistent connection. (Fortunately, _that_ can't
occur, thanks to circuit_consider_sending_sendme. Still, if we
change our windowing logic at all, we won't want this to become
triggerable.) Fix for bug 5541. Bugfix on 4a66865d, back from
0.0.2pre14. asn found this. Nice catch, asn!
This tells the windows headers to give us definitions that didn't
exist before XP -- like the ones that we need for IPv6 support.
See bug #5861. We didn't run into this issue with mingw, since
mingw doesn't respect _WIN32_WINNT as well as it should for some of
its definitions.
MSVC warns if you declare a function as having a "int foo" argument
and then implement it with a "const int foo" argument, even though
the latter "const" is not a part of the function's interface.
Instead, allow packagers to put a 'TOR_BUILD_TAG' field in the
server descriptor to indicate a platform-specific value, if they
need to. (According to weasel, this was his use for the git- tag
previously.)
This is part of 2988
This time, I follow grarpamp's suggestion and move the check for
.exit+AllowDotExit 0 to the top of connection_ap_rewrite_and_attach,
before any rewriting occurs. This way, .exit addresses are
forbidden as they arrive from a socks connection or a DNSPort
request, and not otherwise.
It _is_ a little more complicated than that, though. We need to
treat any .exit addresses whose source is TrackHostExits as meaning
that we can retry without that exit. We also need to treat any
.exit address that comes from an AutomapHostsOnResolve operation as
user-provided (and thus forbidden if AllowDotExits==0), so that
transitioning from AllowDotExits==1 to AllowDotExits==0 will
actually turn off automapped .exit addresses.
This patch changes the total serverdesc threshold from 25% to 75%
and the exit threshold from 33% to 50%. The goal is to make
initially constructed circuits less horrible, and to make initial
less awful (since fetching directory information in parallel with
whatever the user is trying to do can hurt their performance).
Implements ticket 3196.
We were doing an O(n) strlen in router_get_extrainfo_hash() for
every one we tried to parse. Instead, have
router_get_extrainfo_hash() take the length of the extrainfo as an
argument, so that when it's called from
extrainfo_parse_from_string(), it doesn't do a strlen() over the
whole pile of extrainfos.
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
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.
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.
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.
* 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.)
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 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.
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)
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.)
