Thanks to the changes we started making with SocksPort and friends
in 0.2.3.3-alpha, any of our code that did "if (options->Sockport)"
became wrong, since "SocksPort 0" would make that test true whereas
using the default SocksPort value would make it false. (We didn't
actually do "if (options->SockPort)" but we did have tests for
TransPort. When we moved DirPort, ORPort, and ControlPort over to
the same system in 0.2.3.9-alpha, the problem got worse, since our
code is littered with checks for DirPort and ORPort as booleans.
This code renames the current linelist-based FooPort options to
FooPort_lines, and adds new FooPort_set options which get set at
parse-and-validate time on the or_options_t. FooPort_set is true
iff we will actually try to open a listener of the given type. (I
renamed the FooPort options rather than leave them alone so that
every previous user of a FooPort would need to get inspected, and so
that any new code that forgetfully uses FooPort will need fail to
compile.)
Fix for bug 6507.
I don't personally agree that this is likely to be easy to exploit,
and some initial experimention I've done suggests that cache-miss
times are just plain too fast to get useful info out of when they're
mixed up with the rest of Tor's timing noise. Nevertheless, I'm
leaving Robert's initial changelog entry in the git history so that he
can be the voice of reason if I'm wrong. :)
In 0.2.3.18-rc, we started warning on this case while building a
list of missing microdescriptor digests. That turned out to spam
the logs; instead let's warn at parse time.
Partial fix for bug 6404.
The spec requires that every router in a microdesc consensus have an
m line; we weren't obeying that spec.
This creates a new consensus method (13) to allow voting to continue
to work right. Partial fix for bug 6404; fix on 0.2.2.6-alpha.
This is based on a pair of patches from A. Costa. I couldn't apply
those directly, since they changed the generated *roff files, not
the asciidoc source.
Fixes Tor bug 6500 and Debian bug 683359.
This avoids a possible crash bug in flush_from_first_active_circuit.
Fixes bug 6341; bugfix on 0.2.2.7-alpha.
Bug reported and fixed by a pseudonymous user on IRC.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
The SMARTLIST_FOREACH macro is more convenient than BEGIN/END when
you have a nice short loop body, but using it for long bodies makes
your preprocessor tell the compiler that all the code is on the same
line. That causes grief, since compiler warnings and debugger lines
will all refer to that one line.
So, here's a new style rule: SMARTLIST_FOREACH blocks need to be
short.
This could result in bizarre window values. Report and patch
contributed pseudymously. Fixes part of bug 6271. This bug was
introduced before the first Tor release, in svn commit r152.
(bug 6271, part a.)
This reverts commit c32ec9c425.
It turns out the two sides of the circuit don't actually stay in sync,
so it is perfectly normal for the circuit window on the exit relay to
grow to 2000+. We should fix that bug and then reconsider this patch.
I only check on circuits, not streams, since bloating your stream
window past the initial circuit window can't help you much.
Also, I compare to CIRCWINDOW_START_MAX so we don't have surprising
races if we lower CIRCWINDOW_START for an experiment.
With glibc 2.15 and clang 3.0, I get warnings from where we use the
strcpsn implementation in the header as strcspn(string, "="). This
is apparently because clang sees that part of the strcspn macro
expands to "="[2], and doesn't realize that that part of the macro
is only evaluated when "="[1] != 0.
The functions parse_{s,c}method_line() were using
tor_addr_port_lookup() which is capable of doing DNS lookups. DNS
lookups should not be necessary when parsing {C,S}METHOD lines.
The code that detected the source of a remapped address checked that
an address mapping's source was a given rewrite rule if addr_orig had
no .exit, and addr did have a .exit after processing that rule. But
addr_orig was formatted for logging: it was not the original address
at all, but rather was the address escaped for logging and possibly
replaced with "[scrubbed]".
This new logic will correctly set ADDRMAPSRC_NONE in the case when the
address starts life as a .exit address, so that AllowDotExit can work
again.
Fixes bug 6211; bugfix on 0.2.3.17-beta
It turns out this can happen. Even though there is no reason for
connections to be marked but reading, we leave them reading anyway,
so warning here is unwarranted. Let's turn that back on once we do
something sensible and disable reading when we mark. Bugfix for
6203 on Tor 0.2.3.17-beta.
Thanks to cypherpunks for pointing out the general stupidity of the
original code here.
On some platforms, the linker is perfectly happy to produce binaries
that won't run if you give it the wrong set of flags. So when not
cross-compiling, try to link-and-run a little test program, rather
than just linking it.
Possible fix for 6173.
Previously, a directory would check the latest NS consensus for
having the signatures the client wanted, and use that consensus's
valid_until time to set the HTTP lifetime. With this patch, the
directory looks at NS consensus or the microdesc consensus,
depending on what the client asked for.
The warning message of validate_pluggable_transports_config() is
superseded by the changes in the warning message of
connection_or_connect() when the proxy credentials can't be found.
This is a feature removal: we no longer fake any ciphersuite other
than the not-really-standard SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA
(0xfeff). This change will let servers rely on our actually
supporting what we claim to support, and thereby let Tor migrate to
better TLS ciphersuites.
As a drawback, Tor instances that use old openssl versions and
openssl builds with ciphers disabled will no longer give the
"firefox" cipher list.
Manually removed range 0.116.0.0 to 0.119.255.255 which Maxmind says is
assigned to AT. This is very likely a bug in their database, because
0.0.0.0/8 is a reserved range.
From what I can tell, this configuration is usually a mistake, and
leads people to think that all their traffic is getting proxied when
in fact practically none of it is. Resolves the issue behind "bug"
4663.
