| Commit message (Collapse) | Author | Age | Files | Lines |
| |\
| |
| |
| |
| | |
More plumbing for hs connections
See merge request tpo/core/arti!1098
|
| | |
| |
| |
| | |
Apply this churn, which I deferred for ease of review.
|
| | |
| |
| |
| |
| |
| |
| |
| | |
I found that I had the bug where I forgot to call this function, and
reached
bad_api_usage!("The circuit launcher wasn't initialized")
The possibility of such a bug is a hazard of this API pattern.
|
| | |
| |
| |
| |
| | |
Not doing this was a bug. The bug was possible because of some code
duplication between the exit and hs paths. Add a comment about that.
|
| | |
| |
| |
| |
| | |
This will be more convenient inside tor-hsclient. In arti-client,
this mirrors the way TorClient::get_or_launch_exit_circ works.
|
| |/
|
|
|
| |
This commit is mostly code movement; I'd recommend reviewing it
with git's `--color-moved` option.
|
| | |
|
| |
|
|
|
| |
We separated this out in the circmgr API. This is what the HS client
needs. It doesn't want to participate in the general circuit pool.
|
| | |
|
| |
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1071/diffs?commit_id=580fe1118dbbbfa086d11b28e3e26d7c91afe21c#fbd7ab2d6d0a5b515697d4f9f99a42ebd508aa4b_153_165
|
| | |
|
| | |
|
| |
|
|
|
| |
Obviously this still doesn't work because the actual impl in hsclient
is just a todo!().
|
| | |
|
| |
|
|
| |
We want this part for HS too.
|
| |
|
|
|
|
|
|
| |
We're going to want to reuse this.
Also: rename StreamPrefs::isolation and update the docs, to better
reflect its rather limited functionality. The new
TorClient::isolation is the only call site.
|
| |
|
|
|
|
|
| |
Now, a Host has a separate variant for `.onion` which is always used,
even when HS is disabled.
Currently it ends in a todo!.
|
| |
|
|
| |
This is more comprehensible, and will be more convenient.
|
| | |
|
| |
|
|
|
|
|
|
| |
Doing so doesn't seem like a good idea. It might even be some kind of
leak?
Found because I added a variant to `address::Host` for hidden
services, and noticed that the resolve code still compiled.
|
| | |
|
| |
|
|
| |
Fixes #756
|
| | |
|
| |
|
|
|
| |
This panics on error, and we're fine with a panic on misbehavior in
tests.
|
| | |
|
| |
|
|
| |
Fortunately, it adds very little to the arti-client API surface.
|
| |
|
|
|
| |
This is precisely the result of running the rune in
maint/adhoc-add-lint-blocks.
|
| | |
|
| |
|
|
|
|
|
|
| |
There's no harm in doing this, since we'll try to take ownership of
the state soon as soon as we use it: We just want to try early, so
that we'll get it before we decide that we're using bridges.
Fixes bug #669; bug introduced by !889.
|
| |
|
|
|
|
|
|
|
|
| |
This makes a `pt_state` directory inside .local/share/arti (or the
local equivalent), right next to our existing `state` dir.
Ideally we would use a separate directory for each PT, but we have a
very fuzzy "what is a specific PT" notion.
Closes #667
|
| |
|
|
|
|
|
|
| |
If support is available at compile-time, then we construct a PtMgr
and register it with the ChanMgr. We keep a handle to it ourself so
that we can reconfigure it as needed.
Closes #659.
|
| |
|
|
|
|
| |
As per
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/852#note_2854090
(ftaod, that is a different MR to this one)
|
| |
|
|
| |
Fixes #636.
|
| | |
|
| |
|
|
| |
rustfmt only.
|
| |
|
|
| |
We'll need this shortly.
|
| |
|
|
| |
We'll need this shortly.
|
| |\
| |
| |
| |
| | |
Move guardmgr creation to arti-client, rather than within circmgr
See merge request tpo/core/arti!850
|
| | |
| |
| |
| | |
rustfmt only, broken out to ease review.
|
| | |
| |
| |
| |
| |
| |
| | |
Having this done within circmgr was irregular - most of our other key
buildup functions are done in TorClient::create_inner.
It is also inconvenient, as it buries the guardmgr within the circmgr.
|
| |/
|
|
|
|
|
| |
Now the Store is constructed by arti_client, solving the problem
described here
https://gitlab.torproject.org/tpo/core/arti/-/issues/631#note_2853665
but in a different way.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
This is not interesting to the user, and violates some of our
safe-logging rules (like "Don't log at info for each user request"
and "don't log ports").
|
| |
|
|
|
|
| |
Arti is not designed to be a setuid-safe program.
Part of #523.
|
| | |
|
| |
|
|
|
|
|
|
|
| |
This gets rid of many Result(). Many parameters are renamed.
Test cases of the now-impossible branch are removed.
Deleting the match from padding_parameters will come in a moment.
I've split off that commit since it has much whitespace noise.
for now, change the error type to Void.
|
| |
|
|
|
| |
This commit is just the necessary plumbing. The config is currently
empty. We'll add something to it, for padding control, later.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The chanmgr remembers the last dormancy state it was told.
We invent a chanmgr-specific Dormancy which the arti-client code knows
how to convert from the richer top-level dormant status. This avoids
having to have everyone know all the variants of the top-level state.
To call reconfigure_general, we must also obtain and plumb through a
netdir. Right now we must return an internal error if there is in
fact no netdir, because reconfigure_general does not yet cope with a
missing netdir.
Nothing actually *uses* the dormancy yet.
|