| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
The HTTP status text is often useful for diagnosing errors. Tor
directory and hsdir caches frequently put useful messages there,
especially when rejecting an uploaded document.
Inspired by #1142.
|
| | |
|
| |
|
|
|
|
|
|
| |
The effect is that everywhere a RetryError is used, the error sources
for the contained errors will be Display'd.
In tor-hsclient we no longer need to explicitly wrap things up in
tor_error::Report.
|
| |\
| |
| |
| |
| | |
tor-hsclient: Handle handshake completion error correctly
See merge request tpo/core/arti!1336
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
Thsi is a bit of a mouthful now, but it is comprehensible.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1336#note_2917235
|
| | | |
|
| | |
| |
| |
| |
| | |
See
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1336#note_2917236
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
We need to handle errors during the handshake. That also produces a
`tor_proto::Error` but we want to print a different message for that,
so let's rename this before adding the new variant.
|
| | |
| |
| |
| | |
It was wrong where ti was.
|
| | |
| |
| |
| | |
Since arti!1233 this is trivial.
|
| |/
|
|
|
| |
For some reason this wasn't used in the actual errors,
although it *was* used in the types of the functions etc.
|
| | |
|
| |
|
|
| |
Otherwise we'll fill up our RAM with junk.
|
| |\
| |
| |
| |
| | |
tor-hsclient: Expire circuits when they get too old
See merge request tpo/core/arti!1287
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| |
| | |
These have been subsumed by other errorkinds, mostly
OnionServiceProtocolViolation and TorProtocolViolation.
In particular please review the change in tor-hsclient closely;
I am not sure about the new errorkinds for the error there.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
For higher-level HsDesc-related functions, this type indicates where
exactly an error occurred. It lets us distinguish decryption errors
from parsing errors, and attribute responsibility to the hsdir, the
onion service, or the user's lack of encryption.
This lets us remove some just-introduced complexity in
tor-hsclient.
|
| |/
|
|
| |
Part of #736
|
| |
|
|
|
| |
For the arms that have a fixed retry time, or a fixed ErrorKind,
dont't bind the unused inner error.
|
| |
|
|
| |
Add a cross-reference to docs arising from MR comments in !1246.
|
| | |
|
| |
|
|
|
| |
There is a cross-reference here to code (`IptSortKey`) in another
branch that I haven't made an MR for yet.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
If something *other* than a timeout went wrong, then that is less
expected so more interesting.
|
| | |
|
| |
|
|
| |
Without this, the printed errors are very bland.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Remove TODO comment; instead, replace with a comment about future use
for HS server side, inspired by
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228/diffs?commit_id=ecfd39507c4e8d52788f4599d6275cab3b4a2a5f#c0123bb2f6b9a9ca50fa45886b667580a7dc951e_79_82
Do not implment `tor_error::HasKind`; the true kind depends on where
the bad information came from, which the calling code will understand.
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1228/diffs?commit_id=d63ad3ab041460bf85defb99b31d6ebe075a0eb1#c0123bb2f6b9a9ca50fa45886b667580a7dc951e_101_110
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This contains code to:
* Iterate over introduction points
* Make multiple attempts to connect
* Apply timeouts to the various phases of each attempt
* Establish a rendezvous point
* Represent errors that occur during the above
It provides places to add:
* Implementation of the INTRODUCE1/INTRODUCE_ACK handshake
* Reception of RENDEZVOUS2 and actual end-to-end circuit establishment
* Recording of the outcome of connection attempts via particular IPTs
* Using previous IPT outcome information for selecting IPTs to try
* Tests of the new code (although more mocking will probably be needed)
Much of this code works with a fixed type ClientCirc rather than going via
the Mockable traits. That is wrong, and it will be fixed later.
|
| |
|
|
|
|
| |
We're going to want to report about rendezvous points in errors.
We'll do this by printing the "number" of the intro point in the descriptor.
|
| |
|
|
|
| |
We're going to want to report about rendezvous points in errors.
We'll be using this. And we'll want to convert it from a Relay.
|
| |
|
|
|
| |
This factors out an ad-hoc AsRef impl. We're going to want to reuse
this for another error type.
|
| |
|
|
|
|
| |
A `NetdocErrorKind` is a `NEK` rather than a `PEK`.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
| |
`ParseErrorKind` was renamed to `NetdocErrorKind`, so we need to
rename this acccessor too.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
`ParseErrorSource` was originally meant to represent a parsing error,
this enum has since gained some variants that aren't really parsing
related (`Signature`, `CertSignature`, `UntimelyDescriptor`).
Since this error type is now used for general-purpose netdoc errors,
let's rename `ParseError{Kind, Source}` to `NetdocError{Kind, Source}`.
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
| |
Signed-off-by: Gabriela Moldovan <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
!1121 renamed *ProtocolFailed to *ProtocolViolation.
!1118 introduced a new reference to a *ProtocolFailed
I rebased !1118 onto main and enabled automerge. That tested the tip
of !1118. I assume a similar thing happened to !1121.
The possibility of such regressions is a property of our workflow.
It's rather surprising it doesn't happen more often.
|
| | |
|
| |
|
|
|
|
|
|
| |
There are many TODOs here. Some are questions; some are
straightforward and can be done in followups.
With this code, I am able to reach the eprintln! and todo! with
curl --socks5-hostname localhost:9150 https://duckduckgogg42xjoc72x3sjasowoarfbgcmvfimaftt6twagswzczad.onion/
|
| |
|
|
|
| |
The old name was unwieldy and other crates can just as well name it by
the crate scope.
|
| | |
|
| |
|
|
| |
This seems more consistent with the way it's done elsewhere.
|
| | |
|
| | |
|