summaryrefslogtreecommitdiff
path: root/crates/tor-chanmgr/src/builder.rs
Commit message (Collapse)AuthorAgeFilesLines
* linkspec: Rename all_addrs_allowed_for_extend()David Goulet2026-04-091-2/+4
| | | | | | Also set a better error message when validating channel target. Signed-off-by: David Goulet <[email protected]>
* relay: Pass advertise SocketAddr to channel builder instead of IpAddrDavid Goulet2026-04-091-4/+4
| | | | | | | | | | This trickles down to the tor-proto channel handshake code. But, the real need is in the channel builder in order to validate the outbound channel target. Fixes #2440 Signed-off-by: David Goulet <[email protected]>
* chanmgr: Validate the ChanTarget for both client and relayDavid Goulet2026-04-091-41/+64
| | | | | | | | | | It used to be only with the feature = relay but since client can have that feature enabled, we now validate based on channel outbound type instead. Related to #2440 Signed-off-by: David Goulet <[email protected]>
* tor-{proto,chanmgr}: change how channels accept a CREATE* handlerSteven Engler2026-04-081-18/+13
| | | | | | | | | | | Instead of giving the `CreateRequestHandler` to the channel after it's constructed, we integrate it into the handshake so that we can give it to the channel constructor. The `ChannelType` is no longer part of the `Channel`. Some of the tests could be cleaned up slightly now that the channel doesn't need the `ChannelType`, but I don't want to conflict with !3853.
* tor-chanmgr: add support for a `CreateRequestHandler`Steven Engler2026-04-081-2/+56
|
* linkspec: Rename has_all_public_addresses()David Goulet2026-03-301-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* linkspec: Rename has_all_reachable_addresses()David Goulet2026-03-301-1/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* linkspec: Rename has_all_valid_port() to has_all_nonzero_port()David Goulet2026-03-301-2/+2
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Rename RelayIdentities to RelayChannelAuthMaterialDavid Goulet2026-03-301-27/+30
| | | | | | | | | | | | This object contains a melting pot of public keys, private keys and certificates. Rename it to reflect that it is channel authentication material and not "identities. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374454 Signed-off-by: David Goulet <[email protected]>
* proto: Rename many variables with more fine grained namingDavid Goulet2026-03-301-7/+7
| | | | | | | | | | Mostly, identity a `ChanTarget` as a "target" since we juggle with PeerInfo and OwnedChanTarget nowadays. All certificate and keys have very specific names which attempts to match the spec as much as possible. Signed-off-by: David Goulet <[email protected]>
* chanmgr: Always use MaybeSensitive<PeerAddr> when building a channelDavid Goulet2026-03-301-7/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Add a build_client_channel() helper functionDavid Goulet2026-03-301-59/+83
| | | | | | | | | | | | This moves the client channel building code into build_client_channel() to match the build_relay_channel() function pattern. No behavior change, just code movement. Small changes were needeed (reference for instance) but no behavior change. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374448 Signed-off-by: David Goulet <[email protected]>
* chanmgr: Move relay target PT validation in validate_relay_target()David Goulet2026-03-301-6/+9
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Validate the relay channel target addressesDavid Goulet2026-03-301-1/+35
| | | | | | | | | | | | | | | Make sure the port is non zero and that all addresses are globally reachable. Notice the use of ChanProto error in this commit instead of UnusableTarget. Relay channel initiator are opened by the circuit reactor meaning from an EXTEND2 request meaning the target is not controlled by us so any errors is a channel protocol violation. UnusableTarget is an internat Bug. https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3791#note_3374447 Signed-off-by: David Goulet <[email protected]>
* chanmgr: Don't build relay channel if method is not DirectDavid Goulet2026-03-191-0/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Clarify the use of no identity ChanTargetDavid Goulet2026-03-191-6/+10
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Don't get the peer cert as a responder channelDavid Goulet2026-03-191-9/+1
| | | | | | | | No initiator present a TLS certificate and so don't try to get one. Fixes #2388 Signed-off-by: David Goulet <[email protected]>
* safelog: Rename MaybeSensitive::hidden/visible()David Goulet2026-03-031-3/+4
| | | | | | Rename them to respectively sensitive() and not_sensitive(). Signed-off-by: David Goulet <[email protected]>
* chanmgr: Safely log the peer in the channel builderDavid Goulet2026-03-031-15/+21
| | | | | | | | | On I/O error, we safely log the peer address that was used that lead to this error. Closes #2375 Signed-off-by: David Goulet <[email protected]>
* proto: Make channel PeerAddr sensitiveDavid Goulet2026-03-031-1/+6
| | | | | | | Only the R2R channel that the PeerAddr becomes unsensitive. The rest, we keep it sensitive as it can be a client or a client's guard/bridge. Signed-off-by: David Goulet <[email protected]>
* chanmgr: Rename function parameterDavid Goulet2026-02-261-3/+3
| | | | | | | It was _target before because we had it in the function with a cfg_if!(). Now don't so no need. Signed-off-by: David Goulet <[email protected]>
* chanmgr: The validate_relay_target() had its logic inversedDavid Goulet2026-02-261-4/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* Merge branch 'chanbuilder-my-addrs' into 'main'David Goulet2026-02-241-6/+17
|\ | | | | | | | | chanmgr: Store our relay addresses in the builder See merge request tpo/core/arti!3716
| * chanmgr: Responder relay channel now use the builder my_addrsDavid Goulet2026-02-241-2/+1
| | | | | | | | | | | | No need to pass from the arti relay binary our addresses when handling an incoming channel, use the one in the channel builder that an initiator channel uses.
| * chanmgr: Store our relay addresses in the builderDavid Goulet2026-02-241-4/+16
| | | | | | | | | | | | | | | | | | | | We need those addresses when we build a relay channel in order to send them into our NETINFO cell. This adds the `with_my_addrs()` on the `ChanMgrConfig` object. Next commit will make arti-relay use it. Signed-off-by: David Goulet <[email protected]>
* | chanmgr: Don't allow to build relay channel to ourselfDavid Goulet2026-02-241-3/+33
|/ | | | | | | | | | The validate_relay_target() is meant to probably have more checks in the future hence the vagueness of it instead of being specific to the goal of this patch. Closes #1699 Signed-off-by: David Goulet <[email protected]>
* chanmgr: Add a set_relay_identities() to update the RelayIdentitiesDavid Goulet2026-02-241-0/+11
| | | | | | | | | | The arti-relay crate rotates the keys at regular interval which we need to give to the ChanMgr to update its builder. This function boldly replace the default factory with the new identities including the TLS acceptor can pick up the new key. Signed-off-by: David Goulet <[email protected]>
* proto: Modify RelayIdentities to have encodable certDavid Goulet2026-02-231-1/+1
| | | | | | | This commit also adds the TlsKeyAndCert to the identities so the TLS acceptor can set it up. Signed-off-by: David Goulet <[email protected]>
* proto: Pass PeerAddr at the channel handshake finish for initiatorsDavid Goulet2026-02-191-4/+2
| | | | | | | | | | Responder relay handshake requires the peer address at the very start as it sends its NETINFO right away. For initiators, we only need it during the finalization process which is when the NETINFO is sent and the Channel is created. Signed-off-by: David Goulet <[email protected]>
* chanmgr: Add a TODO() for logging PeerAddr instaed of ChanTargetDavid Goulet2026-02-191-0/+4
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Fix channel builder commentDavid Goulet2026-02-191-6/+1
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Use the PeerAddr accross channel handshakeDavid Goulet2026-02-191-23/+27
| | | | | | | This is a large change but it is basically using PeerAddr in the channel builder through the channel handshake code and into the Channel itself. Signed-off-by: David Goulet <[email protected]>
* Merge branch 'mr_3616_rebased' into 'main'Nick Mathewson2026-02-161-1/+1
|\ | | | | | | | | | | | | Mr 3616 rebased Closes #1800 See merge request tpo/core/arti!3681
| * tor-chanmgr: integrate outbound proxy into DefaultTransportNihal2026-02-161-1/+1
| |
* | relay: Pass our TLS cert to the responder verify processDavid Goulet2026-02-121-1/+6
|/ | | | | | | | | | For the responder to build the authentication data, it needs its own certificate of the TLS handshake that it is responding to (as a TLS server). This resolves an important TODO(relay) in the code. Signed-off-by: David Goulet <[email protected]>
* chan: Use Canonicity when choosing a channelDavid Goulet2026-02-121-0/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Use the actual channel target used on connect()David Goulet2026-02-121-16/+21
| | | | | | | | | | | | | | | When connecting, we pass an OwnedChanTarget that can contain a list of IPs of the relay we want to connect to. The connect() picks one and return the actual OwnedChanTarget used as in the real IP address we are using. From that point on, we must only use that as the channel canonicity requires to check against the IP we believe we are connected to. This also is much better to use for error handling considering the error is on the actual channel target, not the hypothetical one. Signed-off-by: David Goulet <[email protected]>
* proto: Channel finish() now handles canonicityDavid Goulet2026-02-121-0/+1
| | | | | | | | | | | | | | All handshake pass the NETINFO cell, the advertised addresses (if any) and the peer address in order to build the Canonicity and build the channel with it. In order to pull this off, the "my_addrs" were added to several object along the NETINFO cell. We also pass the channel method when connecting (initiator) to a relay as we need this for this canonicity build. Signed-off-by: David Goulet <[email protected]>
* proto: Relay responder channel allow to be non_exhaustiveDavid Goulet2026-02-091-1/+0
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Fix the outbound_chan_type() to not be based on relay featureDavid Goulet2026-02-091-10/+4
| | | | | | | A client can have the relay feature enabled. The presence of "identities" is what dictates if we are a relay or not. Signed-off-by: David Goulet <[email protected]>
* chanmgr: Build channel/reactor on incoming connectionsDavid Goulet2026-02-091-6/+74
| | | | | | | | Implement the accept_from_transport() in the ChanBuilder. This returns a `Channel` and spawns a reactor. Signed-off-by: David Goulet <[email protected]>
* relay: Add a TLS acceptor in the ChanBuilderDavid Goulet2026-02-091-12/+39
| | | | | | | | | | | | | | | This requires the `TlsKeyAndCert` so be passed on the TLS acceptor settings. We assume that `RelayIdentities` has this information. The ChanBuilder::new() was getting a bit too convoluted and feature gated to instead we introduce new_client() and new_relay() and remove the need for `with_identities()`. Because of this, the ChanMgr::new() now returns a `Result<>`. Related to #1597 Signed-off-by: David Goulet <[email protected]>
* chanmgr: Always use connect target for error reportingDavid Goulet2026-02-041-14/+6
| | | | Signed-off-by: David Goulet <[email protected]>
* chanmgr: Use the new tor-proto relay channel APIDavid Goulet2026-02-041-43/+112
| | | | | | | | | With specific types now for relay channels, add a function to build the channel and run the reactor. That function is feature gated and thus relay only. Signed-off-by: David Goulet <[email protected]>
* rtcompat: Return certificates as Cow.Nick Mathewson2026-02-021-1/+5
|
* proto: Remove async for VerifiableChannel::check()David Goulet2026-01-221-16/+15
| | | | Signed-off-by: David Goulet <[email protected]>
* proto: Send relay channel NETINFO in check()David Goulet2026-01-221-15/+19
| | | | | | | | | | Once channel is verified and authenticate if need be, send the NETINFO. We require our advertised IP addresses for this so pass them to launch() as well to the UnverifiedRelayChannel. A cargo fmt change slipped in here, sorry about that. Signed-off-by: David Goulet <[email protected]>
* proto: Make VerifiableChannel::check() asyncDavid Goulet2026-01-221-1/+1
| | | | | | | | | Relay initiator needs to send CERTS and AUTHENTICATE in that function after verifiying the channel. And thus require to be async. Signed-off-by: David Goulet <[email protected]>
* relay: Pass advertised addresses to the channel handlerDavid Goulet2026-01-221-1/+2
| | | | | | | | | | | 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]>
* chanmgr: Get rid of the builder outbound_chan_typeDavid Goulet2026-01-131-8/+23
| | | | | | | | | | | | | | | | | | | 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]>
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 21:44:27 +0000