| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| | |/ |
|
| |/ |
|
| | |
|
| | |
|
| |\ |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
Closes #322.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
These errors should almost never be seen by the user; we should instead
retry the circuit. But they _can_ be seen by the use if selecting a
guard takes too long, or too many attempts. (Therefore, they aren't true
"internal" errors.)
I suspect that we might not want to keep this TransientFailure kind, but
I'm not sure what else to do here for now.
|
| | |
| |
| |
| | |
There are a couple of tricky ones I'll do separately.
|
| |/ |
|
| |
|
|
|
|
| |
This took some refactoring, and gave an opportunity to notice
a few error variants that weren't being used, or didn't mean
what they said on the tin.
|
| |
|
|
|
|
|
|
|
| |
Additionally, refactor the IoError out of tor_cell::Error:
nothing in TorCell created this; it was only used by tor_proto.
This required refactoring in tor_proto to use a new error type. Here I
decided to use a new CodecError for now, though we may refactor that
away soon too.
|
| |
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/310#note_2777626
The message from the kind is precisely right.
|
| |
|
|
| |
Now it maches the others
|
| |
|
|
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/310#note_2777519
mutatis mutandi.
And, fix a leftover instance with an old idea of what this was called.
|
| |
|
|
| |
Including supporting machinery, new kind field, etc.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Change deny(clippy::all) to warn(clippy::all).
Closes #338
See merge request tpo/core/arti!306
|
| | |
| |
| |
| | |
Closes #338.
|
| |\ \
| | |
| | |
| | |
| | | |
Split up ErrorKind::ProtocolViolation
See merge request tpo/core/arti!312
|
| | |/ |
|
| |\ \
| | |
| | |
| | |
| | | |
Split up ErrorKind::NoSupport
See merge request tpo/core/arti!311
|
| | |/ |
|
| |/ |
|
| |\
| |
| |
| |
| |
| |
| | |
Allow creating unbootstrapped `TorClient`s (and `DirMgr`s)
Closes #293
See merge request tpo/core/arti!298
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
This commit changes how the `TorClient` type works, enabling it to be
constructed synchronously without initiating the bootstrapping process.
Daemon tasks are still started on construction (although some of them
won't do anything if the client isn't bootstrapped).
The old bootstrap() methods are now reimplemented in terms of the new
create_unbootstrapped() and bootstrap_existing() methods.
This required refactoring how the `DirMgr` works to enable the same sort
of thing there.
closes #293
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Refactor the Error type to remove the yucky internal hidden Truncated
variant. Instead, there's now an embedded tor_bytes::Error value.
If that tor_bytes::Error is Truncated, we bubble it up when we convert our
handshake result to the nested error struct.
Thus there is still (sadly) a variant of tor_socksproto::Error
that shouldn't be exposed to user code. But refactoring every
inner method under handshake.rs seemed like a bad idea: once we're using
Result<Result<..>>, the ? operator no longer helps us much.
|
| | | |
|
| | |
| |
| |
| |
| | |
(This error isn't yet wrapped in TorError, but it will be eventually
when we implement socks proxy and PT support.)
|
| |/
|
|
| |
This required a few new ErrorKinds.
|
| |
|
|
|
|
| |
These tests turned up a need for using the #[track_caller]
annotation in order to get accurate locations, which is fortunately
stable since Rust 1.46.0.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
At least by default, we should have Error be private, and not expose
it as part of our APIs.
To keep functionality in `arti`, I had to add an `ExitTimeout` error
kind.
For interface consistency, I also re-exported ErrorKind and HasError
from `arti_client`.
|
| |
|
|
|
|
| |
This is the first version that builds correctly on our CI. It's
from back in 2018, so requiring it shouldn't cause any major
problems.
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/262#note_2772816
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/262#note_2772810
|
| | |
|