| Age | Commit message (Collapse) | Author |
|---|
|
Now that we support NumEntryGuards, NumDirectoryGuards is pretty
easy to put back in.
|
|
Further, add a "guard-n-primary-guards-to-use" parameter, defaulting
to 1, for NumEntryGuards to override.
|
|
Previously, we had NumEntryGuards kind of hardwired to 1. Now we
have the code (but not the configuarability) to choose randomly from
among the first N primary guards that would work, where N defaults
to 1.
Part of 20831 support for making NumEntryGuards work again.
|
|
It overrides both the GUARD_LIFETIME and the
GUARD_CONFIRMED_MIN_LIFETIME options.
|
|
|
|
It is obsoleted in an always-on direction by prop271.
|
|
|
|
asn found while testing that this function can be reached with
GUARD_STATE_COMPLETE circuits; I believe this happens when
cannibalization occurs.
The added complexity of handling one more state made it reasonable
to turn the main logic here into a switch statement.
|
|
Letting the maximum sample size grow proportionally to the number of
guards defeats its purpose to a certain extent. Noted by asn during
code review.
Fixes bug 20920; bug not in any released (or merged) version of Tor.
|
|
The valid_until check was redundant.
|
|
|
|
- Correctly maintain the previous guard selection in choose_guard_selection().
- Print bridge identifier instead of nothing in entry_guard_describe()._
|
|
|
|
This will make it easier to see what we remove down the line.
|
|
|
|
|
|
|
|
|
|
(That's asking for trouble, and also totally completely redundant.)
|
|
|
|
|
|
|
|
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.
|
|
If a complete circuit C2 doesn't obey the restrictions of C1, then
C2 cannot block C1.
The patch here is a little big-ish, since we can no longer look
through all the complete circuits and all the waiting circuits on a
single pass: we have to find the best waiting circuit first.
|
|
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.
|
|
I had been asking myself, "hey, doesn't the new code need to look at
this "info" parameter? The old code did!" But it turns out that the
old code hasn't, since 05f7336624d6a47b3.
So instead of "support this!" the comment now says "we can remove
this!"
|
|
|
|
|
|
|
|
|
|
Don't restrict the sample size if the network size is less than 20
guards. Maybe we'll think of a better rule later on?
|
|
|
|
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.
|
|
George Kadianakis pointed these out.
|
|
Here we handle most (all?) of the remaining tasks, and fix some
bugs, in the prop271 bridge implementation.
* We record bridge identities as we learn them.
* We only call deprecated functions from bridges.c when the
deprecated guard algorithm is in use.
* We update any_bridge_descriptors_known() and
num_bridges_usable() to work correctly with the new backend
code. (Previously, they called into the guard selection logic.
* We update bridge directory fetches to work with the new
guard code.
* We remove some erroneous assertions where we assumed that we'd
never load a guard that wasn't for the current selection.
Also, we fix a couple of typos.
|
|
Still missing is functionality for picking bridges when we don't
know a descriptor for them yet, and functionality for learning a
bridge ID.
Everything else remains (basically) the same. Neat!
|
|
|
|
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
|
|
This is safe, because no entry_guard_t ever outlives its
guard_selection_t.
I want this because now that multiple guard selections can be active
during one tor session, we should make sure that any information we
register about guards is with respect to the selection that they came
from.
|
|
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.
|
|
|
|
|
|
|
|
If a guard becomes primary as a result of confirming it, consider
the circuit through that guard as a primary circuit.
Also, note open questions on behavior when confirming nonprimary guards
|
|
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.
|
|
(This is required by 3.9 in prop271, but is better done as a
separate function IMO)
|
|
It makes more sense to have a single dirty flag, since we always
regenerate the whole state file when we save it.
|
|
|
