| Age | Commit message (Collapse) | Author |
|---|
|
(Teor wrote the code, nick extracted it into a smaller patch.)
|
|
(Nick extracted this patch from a larger patch by Teor.)
|
|
Self-testing circuits don't use guards, and nobody uses guards when
UseEntryGuards is disabled.
Fixes bug 21007; bug not in any released Tor.
|
|
|
|
|
|
|
|
|
|
|
|
Replace the 81 remaining fallbacks of the 100 originally introduced
in Tor 0.2.8.3-alpha in March 2016, with a list of 177 fallbacks
(123 new, 54 existing, 27 removed) generated in December 2016.
Resolves ticket 20170.
|
|
|
|
In get_token(), we could read one byte past the end of the
region. This is only a big problem in the case where the region
itself is (a) potentially hostile, and (b) not explicitly
nul-terminated.
This patch fixes the underlying bug, and also makes sure that the
one remaining case of not-NUL-terminated potentially hostile data
gets NUL-terminated.
Fix for bug 21018, TROVE-2016-12-002, and CVE-2016-1254
|
|
They broke stem, and breaking application compatibility is usually a
bad idea.
This reverts commit 6e10130e18c80f4521e31b071455ae0b1bbea761,
commit 78a13df15842e8ab262e17825160386fadb77056, and
commit 62f52a888acc191bcb507d27d31d54e42e6effdd.
We might re-apply this later, if all the downstream tools can handle
it, and it turns out to be useful for some reason.
|
|
|
|
|
|
|
|
(Keeping the code around in case I broke Tor in some unexpected
way.)
|
|
|
|
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.
|
|
|
|
Since we already had a separate function for getting the universe of
possible guards, all we had to do was tweak it to handle very the
GS_TYPE_RESTRICTED case.
|
|
|
|
|
|
|
|
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.)
|
|
|
|
|
|
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!
|
