| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | | |
| | |
| | |
| | |
| | | |
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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This seems to fix a bug when running cargo check on netdoc individually.
Reported by @janimo
|
| | |
|
| |
|
|
|
|
|
| |
Now we all both address:port, (address, port), and more.
We also allow SocketAddr and IpAddr, but only via a trait
labeled as "Dangerous".
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| | |
For now, this avoids having to separately handle
AuthorityBuilderError, DirMgrConfigBuilderError, DownloadScheduleConfigBuilderError,
NetworkConfigBuilderError and FallbackDirBuilderError when anyhow is not
used.
Turn off a clippy warning.
|
| | |
| |
| |
| | |
Suggested by @cheako.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The default soft limit is typically enough for process usage on most
Unixes, but OSX has a pretty low default (256), which you can run
into easily under heavy usage.
With this patch, we're going to aim for as much as 16384, if we're
allowed.
Fixes part of #188.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
I don't love this approach, but those errors aren't distinguished by
ErrorKind, so we have to use libc or winapi, apparently. At least
nothing here is unsafe.
Addresses part of #188.
|
| | | |
|
| | |
| |
| |
| |
| | |
Previously we would sometimes fail to report that we had
successfully bootstrapped.
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
(Previously we'd report it as successful even if the inner download
task was a failure.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The previous code would report all failures to build a circuit as
failures of the guard. But of course that's not right: If we
fail to extend to the second or third hop, that might or might not
be the guard's fault.
Now we use the "pending status" feature of the GuardMonitor type so
that an early failure is attributed to the guard, but a later
failure is attributed as "Indeterminate". Only a complete circuit
is called a success. We use a new "GuardStatusHandle" type here so
that we can report the status early if there is a timeout.
|