| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \ \ \ |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
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.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
The `get_relay` function was confusing, since it would return None if
the relay was present, but wasn't actually a guard. We only used it
in one place, and in that one place we used it wrong, leading to a
panic bug.
Fixes #193.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Thanks to the chrono update, we no longer include an
obsolete/vulnerable version of the `time` crate. Unfortunately, it
turns out that chrono has the same trouble as `time`: it, too, looks
at the environment via localtime_r, and the environment isn't
threadsafe.
One step forward, one step back. At least the underlying issue is
one that lots of people seem to care about; let's hope they come up
with a solution.
|