| Age | Commit message (Collapse) | Author |
|---|
|
Closes #13092; patch from dgoulet.
|
|
|
|
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.
|
|
Instead of putting it all in one warning message, log what exactly
was wrong with the circuit.
Resolves ticket 12997.
|
|
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.
|
|
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.
|
|
|
|
|
|
These got committed by mistake.
|
|
We don't actually allow a group name, but the documentation implied
that we did.
|
|
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.
|
|
Conflicts:
src/or/circuitbuild.c
|
|
This fixes a double-define introduced in 28538069b2f1909a7600ec6d
|
|
|
|
|
|
|
|
|
|
|
|
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.
|
|
Prevents other cases of 12848.
|
|
Cypherpunks found this and wrote this patch.
Fix for 12848; fix on (I think) d58d4c0d, which went into 0.0.8pre1
|
|
patch from mttp; fixes 12830
|
|
|
|
When Tor starts with DisabledNetwork set, it would correctly
conclude that it shouldn't try making circuits, but it would
mistakenly cache this conclusion and continue believing it even
when DisableNetwork is set to 0. Fixes the bug introduced by the
fix for bug 11200; bugfix on 0.2.5.4-alpha.
|
|
|
|
into maint-0.2.5
Conflicts:
contrib/dist/tor.service.in
|
|
maint-0.2.5
|
|
|
|
Our current systemd unit uses "Type = simple", so systemd does not expect tor to
fork. If the user has "RunAsDaemon 1" in their torrc, then things won't work as
expected. This is e.g. the case on Debian (and derivatives), since there we pass
"--defaults-torrc /usr/share/tor/tor-service-defaults-torrc" (that contains
"RunAsDaemon 1") by default.
The only solution I could find is to explicitly pass "--RunAsDaemon 0" when
starting tor from the systemd unit file, which this commit does.
|
|
|
|
|
|
|
|
|
|
Those used to be normal to receive on hidden service circuits due to bug
1038, but the buggy Tor versions are long gone from the network so we
can afford to resume watching for them. Resolves the rest of bug 1038;
bugfix on 0.2.1.19.
|
|
|
|
|
|
|
|
Conflicts:
src/or/or.h
|
|
Roger spotted this on tor-dev in his comments on proposal 221.
(Actually, detect DESTROY vs everything else, since arma likes
network timeout indicating failure but not overload indicating failure.)
|
|
This makes FastFirstHopPK an AUTOBOOL; makes the default "auto"; and
makes the behavior of "auto" be "look at the consensus."
|
|
|
|
|
|
This function is supposed to construct a list of all the ciphers in
the "v2 link protocol cipher list" that are supported by Tor's
openssl. It does this by invoking ssl23_get_cipher_by_char on each
two-byte ciphersuite ID to see which ones give a match. But when
ssl23_get_cipher_by_char cannot find a match for a two-byte SSL3/TLS
ciphersuite ID, it checks to see whether it has a match for a
three-byte SSL2 ciphersuite ID. This was causing a read off the end
of the 'cipherid' array.
This was probably harmless in practice, but we shouldn't be having
any uninitialized reads.
(Using ssl23_get_cipher_by_char in this way is a kludge, but then
again the entire existence of the v2 link protocol is kind of a
kludge. Once Tor 0.2.2 clients are all gone, we can drop this code
entirely.)
Found by starlight. Fix on 0.2.4.8-alpha. Fixes bug 12227.
|
|
|
|
Authorities now assign the Guard flag to the fastest 25% of the
network (it used to be the fastest 50%). Also raise the consensus
weight that guarantees the Guard flag from 250 to 2000. For the
current network, this results in about 1100 guards, down from 2500.
This step paves the way for moving the number of entry guards
down to 1 (proposal 236) while still providing reasonable expected
performance for most users.
Implements ticket 12690.
|
|
|
|
|
