| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
This adds the lint to all our crates.
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
| |
We need the advertised addresses for the NETINFO cell when opening a
relay channel. Keep them in the TorRelay object so we can pass them to
the ChanMgr channel handler.
This will also help with config reload where only the local values in
TorRelay will need to be updated.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
To pull this off, ChannelProvider::get_or_launch() needed to change from
"&self" to "self: Arc<Self>" so we could pass self to the spawned task.
This is fine as the caller of ChannelProvider (circuit reactor) has a
Arc<ChanMgr>.
This also removes the PhantomData for the runtime as we now actually use
it.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead, we'll simply use `RelayInitiator` if the identity keys
(identities) struct is set.
This avoids the problem where someone could call outbound_chan_type() of
the ChanMgrConfig and get the wrong channel type if with_identities() is
set after.
This way, a single call, `with_identities()` is what will define the
outbound channel type so no chance of errors.
This also removes the cfg_if {} around the builder creation in a much
more simplified version.
Related to #1599
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
| |
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
| |
This allows us to pass it to the ChanBuilder which will be able to use
this type for the outbound channels.
For now, we do this trick where if we have relay identities, we always
consider that all outbound channels will be RelayInitiator.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
This struct is used to pass configuration parameters to the ChanMgr when
building it.
At the moment, it holds the ChannelConfig and RelayIdentities (feature
gated) which will be used in subsequent commits.
Note that relays do require RelayIdentities to build channels.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
| |
We'll rely on a RelayIdentities to pass in the right keys to the ChanMgr
instead of the entire KeyMgr.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
| |
These are all aimed at figuring out in more detail what's going on
in #2079 and related issues.
|
| |\
| |
| |
| |
| | |
arti-relay: Add OR port listener task
See merge request tpo/core/arti!3396
|
| | |
| |
| |
| |
| | |
For incoming connections, wrap the peer address in `Sensitive` as it
could be a client.
|
| |/
|
|
| |
Run maint/add_warning
|
| | |
|
| | |
|
| |
|
|
| |
This feature has been removed from nightly, in favor of doc_cfg.
|
| |
|
|
|
|
|
| |
This is so a relay can build authenticated channels. Several keys/cert
are required for this that are within the key manager.
Signed-off-by: David Goulet <[email protected]>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
First, run
```
git grep -l "^edition =" |
xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;'
```
Second, manually verify that all Cargo.toml files have changed,
and nothing else has changed.
Third, run cargo fmt again.
|
| |
|
|
| |
See #2060.
|
| |
|
|
|
|
| |
Denies 'mod.rs' files for consistency.
https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
|
| |
|
|
|
|
|
|
| |
In 1.83, this warning triggers on many of our crates.
We're thinking of fixing them all, but for now,
we're going to disable the warning.
This is part of #1765.
|
| |
|
|
|
| |
This contains the `Defer` type, which can be used to defer a closure
until the `Defer` is dropped.
|
| |
|
|
| |
We shouldn't actually reconfigure anything if given `CheckAllOrNothing`.
|
| | |
|
| |
|
|
|
|
|
|
| |
We use the *channel*'s memquota account. This is arguably wrong, but
it's hard to get right now. See #1652.
Change the type of the queue, and the places it's constructed.
The use sites can all stay the same.
|
| |
|
|
|
| |
This gets it as far as the outbound circuit->channel mpsc queue creation.
Also, we provide an accessor for it.
|
| |
|
|
|
|
|
|
|
| |
Plumb through a top-level account. This doesn't have any
channel-specific, circuit-specific or stream-specific accounts yet.
tor-circmgr's and tor-hsclient's *tests* need fake account.
In arti-relay, use a dummy account for now.
|
| | |
|
| |
|
|
|
|
| |
Make it have a summary line of only reasonable size.
While we're here, wrap the body with semantic linefeeds.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
(And similarly rename TcpListener to NetStreamListener,
along with their TcpStream/TcpListener associated types.)
These types are about to become generic over addresses,
and therefore shouldn't be named after TCP.
Renaming was done mostly with Rust Analyzer,
except for some macros that needed to be hand-edited.
(I'll revise the comments in the next commit;
this one is all about renaming.)
|
| |
|
|
|
|
|
|
|
| |
The channel manager in the future will need to be able to receive
incoming streams. The type of the stream depends on an associated type
within `ChannelFactory`, so this commit exposes this associated type
through several other types, eventually to the `ChanMgr`.
The new methods are behind the experimental "relay" feature flag.
|
| |
|
|
|
|
|
|
|
|
| |
This has two advantages:
1. Code is a little easier to follow with generics rather than dynamic
dispatch, especially since the type is fixed at compile time anyways.
2. It allows us to access associated types of the `ChannelFactory`,
which will be useful later for getting the stream type from the
`ChanBuilder`.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Previously, Channel was a type that you could Clone that implicitly
its state. Now, Channel always appears as an Arc<Channel>.
This change has several benefits:
* It makes the relationship between Channel struct and the
underlying channel more clear.
* It enables Channel to participate in the RPC system,
where everything has to be an Arc<.>
* It enables us to have a Weak<Channel>, if we ever want to.
* It will let us move various members out of ChannelDetails.
We did this change a while ago with ClientCirc.
|
| |
|
|
| |
This commit is automatically generated.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Since Rust 1.66, std's default works properly for enums, provided that
the default variant is a unit.
Review all uses of `#[educe(default)]` on enums and replace them with
std where possible, which is most of them.
In 1.66 and later, std's `#[derive(Default)]` doesn't infer any
generic bounds on the derived impl, where it's an enum - since the
unit variant can always be constructed. So this change doesn't add
any generic bounds and is not API-visible.
|
| |
|
|
|
|
|
|
|
| |
Without this change, if the delay is less than one second, the code will
effectively busy-loop until the delay has elapsed. This
potentially leads to deadlock in shadow simulations, and
wastes CPU in real usage.
https://shadow.github.io/docs/guide/limitations.html?highlight=busy#busy-loops
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
Basically, it's all ChanBuilder at some point, and ChanBuilder
has a timeout.
|
| |
|
|
|
| |
This method will let the user construct a channel that isn't
stored or monitored by the ChanMgr.
|
| | |
|
| |\
| |
| |
| |
| | |
Expose channel builder in order to create channels more efficiently in external code
See merge request tpo/core/arti!1374
|