| Age | Commit message (Collapse) | Author |
|---|
|
(Teor wrote the code, nick extracted it. It won't compile yet.)
|
|
This will need some refactoring and mocking.
|
|
This is the same as we fixed in 39f455468731d4746adb729a67.
|
|
|
|
I broke this with 20292ec4974b777d430e7962cc38349c5f82b220 when I
changed the primary guard retry schedule.
|
|
|
|
Now that we support NumEntryGuards, NumDirectoryGuards is pretty
easy to put back in.
|
|
It is obsoleted in an always-on direction by prop271.
|
|
|
|
This will make it easier to see what we remove down the line.
|
|
|
|
|
|
|
|
|
|
|
|
The test assumed that the old rules about handling small max_sample
were in effect, and didn't actually handle that case very well
anyway.
|
|
This is an important thing I hadn't considered when writing prop271:
sometimes you have to restrict what guard you use for a particular
circuit. Most frequently, that would be because you plan to use a
certain node as your exit, and so you can't choose that for your
guard.
This change means that the upgrade-waiting-circuits algorithm needs
a slight tweak too: circuit A cannot block circuit B from upgrading
if circuit B needs to follow a restriction that circuit A does not
follow.
|
|
|
|
George pointed out that (-1,0,1) for (never usable, maybe usable
later, usable right now) was a pretty rotten convention that made
the code harder to read.
|
|
This includes:
* making bridge_info_t exposed but opaque
* allowing guards where we don't know an identity
* making it possible to learn the identity of a guard
* creating a guard that lacks a node_t
* remembering a guard's address and port.
* Looking up a guard by address and port.
* Only enforcing the rule that we need a live consensus to update
the "listed" status for guards when we are not using bridges.
|
|
This prevents us from mixing up multiple guard_selections
|
|
Currently, this code doesn't actually have the contexts behave
differently, (except for the legacy context), but it does switch
back and forth between them nicely.
|
|
|
|
|
|
|
|
Some of these will get torrc options to override them too; this
is just the mechanical conversion.
Also, add documentation for a couple of undocumented (but now used)
parameters.
|
|
We frequently want to check a networkstatus parameter only when it
isn't overridden from the torrc file.
|
|
|
|
|
|
(Plus some magic to prevent and detect recursive invocation of
entry_guards_update_primary(), since that can cause some pretty
tricky misbehavior.)
|
|
Act I.
" But that I am forbid
To tell the secrets of my prison-house,
I could a tale unfold..."
Here's the bug: sometimes, rend_cache/store_v2_desc_as_client would
say:
"Dec 15 08:31:26.147 [warn] rend_cache_store_v2_desc_as_client():
Bug: Couldn't decode base32 [scrubbed] for descriptor id. (on Tor
0.3.0.0-alpha-dev 4098bfa26073551f)"
When we merged ade5005853c17b3 back in 0.2.8.1-alpha, we added that
test: it mangles the hidden service ID for a hidden service, and
ensures that when the descriptor ID doesn't match the descriptor's
key, we don't store the descriptor.
How did it mangle the descriptor ID? By doing
desc_id_base32[0]++;
So, if the hidden service ID started with z or 7, we'd wind up with an
invalid base32 string, and get the warning. And if it started with
any other character, we wouldn't.
That there is part 1 of the bug: in 2/32 cases, we'd get a BUG
warning. But we wouldn't display it, since warnings weren't shown
from the unit tests.
Act II.
"Our indiscretion sometime serves us well,
When our deep plots do pall"
Part two: in 0.2.9.3-alpha, for part of #19999, we turned on BUG
warnings in the unit tests, so that we'd actually start seeing them.
At this point we also began to consider each BUG warning that made
it through the unit tests to be an actual bug. So before this
point, we wouldn't actually notice anything happening in those 2/32
cases.
So, at this point it was a nice random _visible_ bug.
Act III.
"Our thoughts are ours, their ends none of our own"
In acbb60cd6310d30c8cb763, which was part of my prop220 work, I
changed how RSA key generation worked in the unit tests. While
previously we'd use pre-made RSA keys in some cases, this change
made us use a set of pregenerated RSA keys for _all_ 1024 or 2048
keys, and to return them in a rotation when Tor tried to generate a
key.
And now we had the heisenbug: anything that affected the number of
pregenerated keys that we had yielded before reaching
rend_cache/store_v2_desc_as_client would make us return a different
key, which would give us a different base32 ID, which would make the
bug occur, or not. So as we added or removed test cases, the bug
might or might not happen.
So yeah. Don't mangle a base32 ID like that. Do it this way instead.
|
|
|
|
|
|
|
|
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Test for both v2 and v3 ESTABLISH_INTRO handling.
|
|
The new HS circuitmap API replaces old public functions as follows:
circuit_clear_rend_token -> hs_circuitmap_remove_circuit
circuit_get_rendezvous -> hs_circuitmap_get_rend_circ
circuit_get_intro_point -> hs_circuitmap_get_intro_circ_v2
circuit_set_rendezvous_cookie -> hs_circuitmap_register_rend_circ
circuit_set_intro_point_digest -> hs_circuitmap_register_intro_circ_v2
This commit also removes the old rendinfo code that is now unused.
It also fixes the broken rendinfo unittests.
|
|
|
|
|
|
|
|
|
|
This test helper had a memory leak on failure, which Coverity Scan
doesn't like. Closes CID 1375996 and 1375997. Not in any released
Tor.
|
|
|
|
|
|
Closes #20938
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
Circuit object wasn't freed correctly. Also, the cpath build state object
needed to be zeroed else we were freeing garbage pointers.
Closes #20936
Signed-off-by: David Goulet <dgoulet@torproject.org>
|
|
This was breaking the build on debian precise, since it thought that
using a 'const int' to dimension an array made that array
variable-size, and made us not get protection.
Bug not in any released version of Tor.
I will insist that this one wasn't my fault.
"Variables won't. Constants aren't." -- Osborn's Law
|
|
|
|
|
|
|
