| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
Closes #1013.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Fixes CI. There was a semantic conflict between !1535 (which added a
suppression) and !1523 (which added a new module).
|
| |\
| |
| |
| |
| | |
hss: use send_raw_msg in rend_handshake.
See merge request tpo/core/arti!1536
|
| | | |
|
| | |
| |
| |
| | |
One of rustfmt's changes here is wrong. Whatever.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
Now new() only has a reasonable number of arguments and removes some
repetition in the mocking arrangements in the IPT Manager.
This is the minimum amount that needs to be done in the commit that
touches both the IPT Establisher and the Manager.
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1523#note_2934367
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1523#note_2934299
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1523#note_2934300
|
| | |
| |
| |
| |
| | |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1523#note_2934298
|
| | | |
|
| | |
| |
| |
| | |
There are many TODOs and no tests, but it does compile.
|
| | |
| |
| |
| |
| |
| | |
I still think putting these in svc/ module doesn't make much sense.
Anyway, we can leave them there for now, but I need to get at them
from crate::ipt_establisher.
|
| | | |
|
| | |
| |
| |
| |
| | |
This module is perhaps rather more comprehensive than needed right
now. But I found I kept wanting to change which bits of it I used.
|
| | | |
|
| | | |
|
| | | |
|
| | | |
|
| | |
| |
| |
| | |
We don't actually want to distinguish drop from not-drop.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
We need a type that holds a rend_handshake::IntroRequest object
internally, but where we don't materialize that object from the
Introduce2 message inside the MsgHandler, since that's more crypto
than we want to put in that task.
|
| | |
| |
| |
| | |
This ensures that the status becomes Faulty when the reactor exits.
|
| | |
| |
| |
| | |
This does not yet do exactly what's documented, but it's closer.
|
| | |
| |
| |
| |
| | |
(This requires us to change the type of the data sent in the
stream. I hope to put it back soon.)
|
| | | |
|
| | |
| |
| |
| |
| | |
This solves some problems but introduces a few new ones; I've tried
to open comments for the latter.
|
| |/ |
|
| |\
| |
| |
| |
| | |
hsservice: Compute rendezvous points correctly.
See merge request tpo/core/arti!1521
|
| | | |
|
| | |
| |
| |
| |
| |
| |
| | |
This duplicates some code from hsclient as noted in the comments;
it might be good to reduce this, but the remaining nontrivial
duplication is small, and the logic flow is slightly different
because of the two-step process.
|
| |\ \
| | |
| | |
| | |
| | | |
tor-hsservice errors: Introduce more error types
See merge request tpo/core/arti!1515
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
At the very least, I need FatalError to be distinct:
IptEstablisher::new ought not to fail unless everything is terrible.
Add a the Spawn variant to FatalError (that we'll need soon) and the
Bug variant (which it seems likely we might need).
This also gets rid of the crate-level Result alias.
|
| | | |
| | |
| | |
| | | |
This is what we do elsewhere.
|
| | | |
| | |
| | |
| | |
| | |
| | | |
If the service encouters operational errors, surfacing them here is
not helpful. So these methods ought to work, if they weren't called
erroneously.
|
| | | |
| | |
| | |
| | |
| | | |
The semantics of an Err return from this are unclear. Was it stopped?
And what kind of error might we even return?
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We want to change the error return types of many methods, so we need a
way to name `std::result::Result`.
We could use `StdResult`, but, actually, properly distinguishing the
kinds of errors that can occur in various contexts means we don't
actually want a single Error type for the whole crate, so
`crate::Result` is going to go away.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Define drop behaviour of IPT establisher, wrt status watch
See merge request tpo/core/arti!1516
|
| | | | | |
|
| | |_|/
|/| |
| | |
| | | |
I had incorrectly thought that this function was private.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | |
| | | |
| | | | |
tor-proto: Make ClientCirc::allow_stream_requests take a HopNum.
Closes #1009
See merge request tpo/core/arti!1519
|
| | |/ /
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
For consistency with the other `ClientCirc` APIs,
`ClientCirc::allow_stream_requests` now takes a `HopNum` argument. Upon
receiving an incoming stream request, the reactor now checks if the
request came from the hop specified in `allow_stream_requests` (and if
it came from a different hop, the circuit is closed).
Part of #1009
|
| |/ /
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The IptEstablisher needs to continuously maintain the IPT even as the
netdir is updated. Whereas, the IPT manager just wants to select the
relay from the netdir once and then only think about the relay
identity.
So it makes sense for the establisher to do necessary lookups of the
relay's ids in the netdir.
|
| |\ \
| |/
|/|
| |
| | |
hsservice: new rend_handshake module
See merge request tpo/core/arti!1512
|