| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
| |
This uses similar techniques to the commit I just did for Fallbacks.
|
| |
|
|
|
|
| |
Now the primary exposed function is `pick_guard` again.
This commit is just function renaming.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
At the site of modify_hop, we now have a comment explaining the
internal-error issue.
To make the internal error less likely, we lower the modify_hop call
in lib.rs into GuardSet, where it can make sure it's looking at the
same filter as was used to select the guard.
The function name "pick_guard_ext" is not permanent; I'm going to
rename it in the next commit.
|
| |
|
|
|
|
|
|
|
| |
Previously, the API said "you need to call this in a loop till it
returns false". We did that in one place, but not another.
With the introduction of filters, forgetting to loop here becomes a
bug: so instead, change the behavior of extend_sample_as_needed so
it handles looping itself.
|
| |
|
|
|
| |
These all say, in one form or another, "there is no guard filtering;
there is only one selection". That's now false.
|
| |
|
|
|
|
|
|
| |
Since a guard can have a bunch of addresses, and the guard is
permitted if any one of those addresses is permitted, then we might
decide to use a guard with some non-permitted addresses. Thus, we
need to filter those addresses before returning the view of the
guard as a FirstHop.
|
| |
|
|
|
| |
Run rustfmt. Separate commit to make review of the substantive commit
easier.
|
| |
|
|
|
| |
This is a *lot* of unwraps. The function takes no parameters and
is used only for testing. It ought to be infallible.
|
| |
|
|
|
| |
(This is just a placeholder; I'm going to make the functions
smarter in the next commit.)
|
| |
|
|
| |
(It is not yet actually used.)
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
The old version of this function was error-prone, and in fact had
errors: it was too easy to forget to add non-persistent fields, and
that's exactly what we forgot in a few cases
(`microdescriptor_missing`, `circ_history`, and
`suspicious_behavior_warned`).
The new version of this function consumes both of the incoming
Guards, and constructs every field explicitly so that we can't
forget to list any.
Closes #429.
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, we treated successfully building a circuit to a guard as
a "success", and any failure, including a directory cache failure,
as a failure. With this change, guards now have separate
success/failure and retry status for circuit usage and directory
usage.
This change is needed for guard-as-directory retry to have
reasonable behavior. Otherwise, when a guard succeeds at building a
circuit, that clears the directory-is-failing status and makes us
retry the guards to quickly.
|
| |
|
|
|
|
|
|
|
|
|
| |
The FirstHopId type now records an enum that stores whether the hop
is a guard or a fallback. This change addresses concerns about
remembering to check the type or source of an Id before passing it
down to the FallbackState or GuardSet.
Making this change required an API change, so that dirmgr can
report success/failure status without actually knowing whether it's
using a fallback or a guard.
|
| |
|
|
|
| |
This is preparation for having separate GuardId and FirstHopId types
that distinguish which back-end they index.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
We need to extend our notion of "the origin of a guard" to include
"somewhere outside the guard list"; we need the ability to return a
FallbackDir as a Guard; and we need to remember a few more pieces of
information in each pending request.
As before, this commit may break compilation; it will be restored soon.
|
| |
|
|
| |
This is more in keeping with the rest of our code.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Don't use SystemTime::now()
Closes #306
See merge request tpo/core/arti!365
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
We'll need this so that we can say "This guard behaved bogusly
as a directory cache; try somebody else."
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When all guards are down, we would previously mark them all as up,
and retry aggressively. But that's far too aggressive: if there's
something wrong with our ability to connect to guards, it makes us
hammer the network over and over, ignoring all the guard retry
timeouts in practice.
Instead,
* We now allow the `pick_guard()` function to fail without
automatically retrying.
* We give different errors in the cases when all our guards are
down, and when all of the guards selected by our active usage
are down.
* Our "guards are down" error includes the time at which a guard
will next be retriable.
This is part of #407.
|
| |\
| |
| |
| |
| |
| |
| | |
guardmgr: Use a better persistent data format
Closes #176
See merge request tpo/core/arti!233
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Previously we stored only one guard sample, in a state file called
"default_guards". That's not future-proof, since we want to have
multiple samples in the future. (`guard-spec.txt` specifies
separate samples for highly restrictive filters, and for bridge
usage.)
This patch changes our behavior so that we can store multiple
samples in a new "guards" file.
I had thought about automatically migrating from the previous file
format and location, but I don't think that's necessary given our
current (lack of) stability guarantees.
Closes #176.
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
| |
This test should only fail very rarely (around 1/2.4e8) when guards
are chosen from a list of 20 with uniform probability. But that
wasn't what we were doing on the mock test network: we were choosing
from a list of 10 viable guards, with nonuniform probability.
As a fix, we change the test network probabilities so that the
guards _are_ chosen with a uniform probability for this test, and we
use a modified version of the test network where there are indeed 20
Guard-flagged relays with the required DirCache=2 protocol.
Closes #276.
|
| | |
|
| |
|
|
|
|
|
| |
We need this information to know if it's okay to migrate to a new
NetDir, or if we need to download more information first.
Part of #178.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`tor-rtcompat`'s `TlsConnector` trait previously included a method to
create a TLS-over-TCP connection, which implied creating a TCP stream
inside that method. This commit changes that, and makes the function
wrap a TCP stream, as returned from the runtime's `TcpProvider` trait
implementation, instead.
This means you can actually override `TcpProvider` and have it apply to
*all* connections Arti makes, which is useful for issues like arti#235
and other cases where you want to have a custom TCP stream
implementation.
This required updating the mock TCP/TLS types in `tor-rtmock` slightly;
due to the change in API, we now store whether a `LocalStream` should
actually be a TLS stream inside the stream itself, and check this
property on reads/writes in order to detect misuse. The fake TLS wrapper
checks this property and removes it in order to "wrap" the stream,
making reads and writes work again.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
| |
We define "coming back online" as happening when a guard attempt
succeeds, if that attempt that was launched when we seemed to be
offline.
We define "seeming to be offline" as having all of our primary
guards marked unreachable, and having received no incoming network
traffic in a while.
Closes #216.
|
| |
|
|
|
|
|
|
|
|
| |
As per arti#175, we'd like to be able to handle newer Arti versions
storing additional state in the persisted state files, without dropping
this data on the floor when we write out changes to these files.
Use the #[serde(flatten)] mechanism to achieve this, by adding catch-all
HashMap<String, JsonValue> fields to all structs that are at risk of
this happening to them.
|
| |
|
|
| |
I'm not sure what I was thinking here.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We now track, for every guard: the total number of successful
circuits we've built through it, along with the total number of
"indeterminate" circuits.
Recall that a circuit's status is "indeterminate" if it has failed
for a reason that _might_ be the guard's fault, or might not be the
guard's fault. For example, if extending to the second hop of the
circuit fails, we have no way to know whether the guard deliberately
refused to connect there, or whether the second hop is just offline.
But we don't want to forgive all indeterminate circuit failures: if
we did, then a malicious guard could simply reject any second hops
that it didn't like, thereby filtering the client into a chosen
set of circuits.
As a stopgap solution, this patch now makes guards become
permanently disabled if the fraction of their circuit failures
becomes too high.
See also general-purpose path bias selection (arti#65), and Mike's
idea for changing the guard reachability definition (torspec#67).
This patch doesn't do either of those.
Closes #185.
|
| |
|
|
| |
Closes #202.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
By the time I merge this, most of the comments should have tickets
to go with them.
|
| | |
|
|
|
There are some missing parts here (like persistence and tests)
and some incorrect parts (I am 90% sure that the "exploratory
circuit" flag is bogus). Also it is not integrated with the circuit
manager code.
|
