Tor Browser includes several ClientTransportPlugin lines in its
torrc-defaults file, leading every Tor Browser user who looks at her
logs to see these notices and wonder if they're dangerous.
Resolves bug 13124; bugfix on 0.2.5.3-alpha.
Technically, we're not allowed to take the address of a member can't
exist relative to the null pointer. That makes me wonder how any sane
compliant system implements the offsetof macro, but let's let sleeping
balrogs lie.
Fixes 13096; patch on 0.1.1.9-alpha; patch from "teor", who was using
clang -fsanitize=undefined-trap -fsanitize-undefined-trap-on-error -ftrapv
Back in 078d6bcd, we added an event number 0x20, but we didn't make
the event_mask field big enough to compensate.
Patch by "teor". Fixes 13085; bugfix on 0.2.5.1-alpha.
Most of these are in somewhat non-obvious code where it is probably
a good idea to initialize variables and add extra assertions anyway.
Closes 13036. Patches from "teor".
It's now a protocol-warn, since there's nothing relay operators can
do about a client that sends them a malformed create cell.
Resolves bug 12996; bugfix on 0.0.6rc1.
The fix for bug 4647 accidentally removed our hack from bug 586 that
rewrote HashedControlPassword to __HashedControlSessionPassword when
it appears on the commandline (which allowed the user to set her own
HashedControlPassword in the torrc file while the controller generates
a fresh session password for each run).
Fixes bug 12948; bugfix on 0.2.5.1-alpha.
Two bugs here:
1) We didn't add EXTEND2/EXTENDED2 to relay_command_to_string().
2) relay_command_to_string() didn't log the value of unrecognized
commands.
Both fixed here.
This will fix the warning
"/src/or/config.c:6854:48: error: unused parameter 'group_readable'"
that I introduced while fixing 12864.
Bug not in any released version of Tor.
When we merged the cookieauthfile creation logic in 33c3e60a37, we
accidentally took out this feature. Fixes bug 12864, bugfix on
0.2.5.1-alpha.
Also adds an ExtORPortCookieAuthFileGroupReadable, since there's no
reason not to.
I looked for other places where we set circ->n_chan early, and found
one in circuit_handle_first_hop() right before it calls
circuit_send_next_onion_skin(). If onion_skin_create() fails there,
then n_chan will still be set when circuit_send_next_onion_skin()
returns. We should probably fix that too.