| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
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.
|
| | | | |
|
| | | | |
|
| | | | |
|
| |\ \ \ |
|
| | | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
Now that we have two kinds of isolation tokens (those set on a
stream, and those set by the stream's associated TorClient), we
need a more sophisticated kind of isolation.
This fixes the bug introduced with the previous commit, where
per-stream tokens would override per-TorClient tokens.
|
| | |/ /
| | |
| | |
| | |
| | | |
When two TorClients are isolated, their streams shouldn't share
circuits, even though they share internal circuit and guard state.
|
| |/ /
| |
| |
| | |
We need this now that we check for contributory behavior.
|
| | |
| |
| |
| | |
Closes #202.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
(This appears to be the emerging consensus of how to handle
RUSTSEC-2020-0159.)
|
| | |
| |
| |
| |
| | |
(This appears to be the emerging consensus of how to handle
RUSTSEC-2020-0159.)
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Solves a name conflict with the existing tor_client create.
Closes #130.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
Previously our code would clear the 'pending' flag on a consensus
only when a _downloaded_ md made it become usable.
Closes #199.
|
| | | |
| | |
| | |
| | |
| | | |
The futures::lock::Mutex was unnecessary, since we never held it
when we were suspending.
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This is a big change, but it does simplify the type of Builder a
little, and isolates locking across different (potential) timeout
estimator types.
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | | |
It's useful to know now only if we now have the lock, but also if we
just got it for the first time.
|
| | | |
| | |
| | |
| | |
| | | |
We can use this in the case where we don't get the lock on the
state file, because another process is running.
|
| | | |
| | |
| | |
| | |
| | | |
Previously we'd try to grab the lock the first time we wrote to the
file.
|
| | |/
|/|
| |
| |
| |
| | |
Closes #200
Signed-off-by: David Goulet <[email protected]>
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
(One represents code that I forgot to write.)
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
The new `hyper` tor-client example demonstrates integrating arti with the
popular Rust `hyper` HTTP library by implementing a custom Hyper "connector"
(a type that can initiate connections to HTTP servers) that proxies said
connections via the Tor network.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
This will let callers use the tokio traits on these types too, if
they call `split()` on the DataStream.
(Tokio also has a `tokio::io::split()` method, but it requires a
lock whereas `DataStream::split()` doesn't.)
|
| | | |
|
| |\ \ |
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
futures::io::AsyncRead (and Write) isn't the same thing as tokio::io::AsyncRead,
which is a somewhat annoying misfeature of the Rust async ecosystem (!).
To mitigate this somewhat for people trying to use the `DataStream` struct with
tokio, implement the tokio versions of the above traits using `tokio-util`'s
compat layer, if a crate feature (`tokio`) is enabled.
|
| | | | |
|
| |/ / |
|
| |/
|
|
|
|
|
|
|
|
|
|
|
| |
The three arguments TorClient::bootstrap requires by way of configuration
have been factored into a new TorClientConfig object.
This object gains two associated functions: one which uses `tor_config`'s
`CfgPath` machinery to generate sane defaults for the state and cache
directories, and one that accepts said directories in order to create a
config object with those inserted.
(this commit was inspired by trying to use arti as a library and being somewhat
overwhelmed by the amount of config stuff there was to do :p)
|
| |
|
|
| |
Also, tell the "typos" tool to ignore Cargo.lock.
|
| | |
|
| |
|
|
|
|
| |
Previously we'd say that we were "waiting for the other process to
bootstrap" even if it was already bootstrapped: and we wouldn't
actually declare success when it was done.
|