aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-proto/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
* add_warning: add reference to arti#2556Jim Newsome2026-07-151-1/+1
|
* lib.rs: remove stale commentJim Newsome2026-07-151-2/+0
|
* Removed unnecessary lintpryty262026-07-151-2/+1
| | | | Removed unnecessary lint
* proto: Make the stream module pubGabriela Moldovan2026-06-171-1/+1
|
* maint: Run maint/add_warning to deny string slicesClara Engler2026-06-091-0/+2
| | | | | | | | | | | | This commit executes maint/add_warning with the just added change to deny string slices except in tests. I recommend auditing this by checking out the previous commit followed by running the script yourself and then verifying that the diff is identical to this commit. This commit makes cargo clippy fail. We will add exceptions in the next commit.
* proto: Rename RelayIdentities to RelayChannelAuthMaterialDavid Goulet2026-03-301-1/+1
| | | | | | | | | | | | 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: Add PeerInfo and PeerAddr in src/peer.rsDavid Goulet2026-02-191-0/+1
| | | | | | | | | | | | | | The plan is to create PeerInfo when we do a transport connect() which indicates the exact values that are being used for to connect to the peer. We'll then put this struct in the Channel so we can use it when picking the best channel in the ChanMgr. Unfortunately, the OwnedChanTarget has a confusing and even possibly wrong API from which we can't have guarantees. Signed-off-by: David Goulet <[email protected]>
* Allow clippy::collapsible_if to triggerGabriela Moldovan2026-02-161-0/+1
| | | | | | | | | `clippy::collapsible_if` started triggering after bumping the MSRV to 1.88. Since this triggers from a lot of places, and since there even are a couple of instances where we explicitly allow `clippy::collapsible_ifs`, I've opened #2342 for deciding what to do about it.
* maint/add_warning: Run script to add new warningGabriela Moldovan2026-01-271-0/+1
| | | | This adds the lint to all our crates.
* proto: Add traits for public channel viewsDavid Goulet2026-01-131-1/+1
| | | | | | | | | | | | | | Add traits that will be returned outside tor-proto allowing us to not expose client and relay specific channels. The goal is for the tor-chanmgr to get those objects implementing those traits and can build and run the reactor without knowing the specific underlying type. This allows us to have less code duplication and less client/relay distinction in the chanmgr. Signed-off-by: David Goulet <[email protected]>
* Remove unnecessary `doc(cfg(...))` attributesNeel Chauhan2025-12-041-1/+0
| | | | | | | | | Fixes part of #2193. (Edits from nickm: I selected the cases here that I could verify were correct from immediate context.) Edited-by: Nick Mathewson <[email protected]>
* Merge branch 'relay-circ' into 'main'David Goulet2025-11-101-1/+1
|\ | | | | | | | | proto: Rename RelayReatorHandle to RelayCirc, make it pub See merge request tpo/core/arti!3410
| * proto: Make RelayCirc publicGabriela Moldovan2025-10-291-1/+1
| |
* | Fix name of clippy lint to unchecked_time_subtraction (2)Ian Jackson2025-11-061-2/+2
|/ | | | Run maint/add_warning
* proto: Add a relay channel builderDavid Goulet2025-10-231-1/+1
| | | | | | | | | | The client and relay channel builder don't share anything and return different objects hence the seperation. Furthermore, this seperation avoids having the client ChanMgr ability to launch relay channels. Signed-off-by: David Goulet <[email protected]>
* proto: Add RelayIdentities object holding our keysDavid Goulet2025-10-231-0/+2
| | | | | | | | | | | | | | | This is a intermediary object between tor-chanmgr and tor-proto that is when building a relay channel, those keys/certs need to be set in the ChannelBuilder so the tor-proto can use them to authenticate. We avoid that way making tor-proto depending on tor-keymgr for the ultimate goal to avoid tor-proto to have access to all the keys in the KeyMgr. Future commits will introduce a relay channel builder which will use that object to set the keys. Signed-off-by: David Goulet <[email protected]>
* proto: Move streammap out of the client moduleGabriela Moldovan2025-10-211-0/+1
|
* proto: Move flow_ctrl module under stream (fmt).Gabriela Moldovan2025-10-071-1/+1
|
* proto: Move flow_ctrl module under stream.Gabriela Moldovan2025-10-071-1/+1
| | | | This will be used by exits too, so I am moving it out of `client`.
* proto: Add a top-level stream module.Gabriela Moldovan2025-10-071-0/+1
| | | | | This will house the implementation-agnostic stream types and functionality.
* Remove "doc_auto_cfg" incantation from all crates.Nick Mathewson2025-09-291-1/+1
| | | | This feature has been removed from nightly, in favor of doc_cfg.
* tor-proto: add pub `CellCount`Steven Engler2025-09-151-1/+1
|
* tor-proto: add struct `FlowCtrlParameters`Steven Engler2025-09-111-0/+1
|
* proto: Move cmd_counts_towards_seqno to a new conflux module.Gabriela Moldovan2025-09-041-0/+1
| | | | | | | `tor_proto::conflux` is where the shared conflux logic will live. Soon the generic parts of the conflux handlers will be moved there (whereas the client-specific `AbstractConfluxMsgHandler` impl will continue living under `tor_proto::client`).
* proto: Move TunnelId to a separate, shared module.Gabriela Moldovan2025-08-281-0/+1
| | | | | | | | | | | | | The `TunnelId*` types will be reused in the relay reactor (exit relays need to have the concept of a "tunnel ID" because of conflux). Now the `relay::reactor` module only has a single import from `client` (for the `unwrap_or_shutdown` helper, which we should be able to remove soon). From now, we will avoid importing anything from `client` in the `relay` module, and instead prefer refactoring the code as needed (to pull the implementation-agnostic parts outside of `client`). This commit has no functional changes, just code motion.
* proto: Add a circuit module shared between client and relay impls.Gabriela Moldovan2025-08-281-1/+2
| | | | | | | This is just code motion (I suggest reviewing with `--color-moved`). This also moves the implementation-agnostic parts from `tor_proto::client::circuit` to a new `tor_proto::circuit` module.
* proto: Move the `stream` module under `client` (breaking).Gabriela Moldovan2025-08-181-2/+1
| | | | | | | | | | | | The `stream` module is client-specific, for the most part, so I am moving it under `client`. Later on, we will factor out the parts that can be shared with the relay implementation. Note: this is a breaking change as the deleted `stream` module was `pub`. We could've kept the module and reexported from it the public types from `tor_proto::client::stream`, but I think it's better to have this `client` namespacing, because it makes the separation between the client and relay parts clearer.
* proto: Rename the `tunnel` module to `client` (fmt).Gabriela Moldovan2025-08-181-1/+1
|
* proto: Rename the `tunnel` module to `client`.Gabriela Moldovan2025-08-181-5/+5
| | | | | | The implementation from `tunnel` is client-specific, so we are renaming the module accordingly. The more generic parts will be pulled into a separate module in a future commit.
* proto: Reorganize relay_tunnel module.Gabriela Moldovan2025-08-181-1/+1
| | | | | | | This reorganizes the `relay_tunnel` module as per @dgoulet's [suggestion]. [suggestion]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3162/diffs#note_3240092
* proto: Add a new relay_tunnel module.Gabriela Moldovan2025-08-181-0/+3
| | | | | | | The new relay tunnel reactor will live in this module for now. This is temporary, as I expect we will soon need to reorganize this crate a little bit, to more clearly separate the client-specific parts from the relay ones.
* Merge branch 'enable-cgo' into 'main'Nick Mathewson2025-08-071-3/+9
|\ | | | | | | | | Enable counter-galois onion negotiation and make it work. See merge request tpo/core/arti!3133
| * proto: List CGO-related features in supported_client_protocolsNick Mathewson2025-08-061-3/+9
| |
* | Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-071-3/+3
|/ | | | | | | | | | | | | | 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.
* tor_proto: add FLOWCTRL_CC to supported_client_protocolsNick Mathewson2025-08-061-5/+15
| | | | | Since we now allow it to be turned on, we can include it among our supported protocols.
* proto, circmgr: Fix feature-gating.Gabriela Moldovan2025-08-051-1/+2
|
* tunnel: Implement start_conversation() for all tunnel typesDavid Goulet2025-08-051-0/+6
| | | | | | | | | | The BaseTunnel now has a start_conversation() which takes a TargetHop meaning it can be used with a multi path tunnel. The Conversation object has been moved into the tunnel namespace out of the circuit one. Signed-off-by: David Goulet <[email protected]>
* proto: Add a new ClientTunnel typeGabriela Moldovan2025-08-051-1/+1
| | | | | | | | | | | | | | | | | | To use the functionality only allowed on single-circuit tunnels (such as `extend*`), callers will have to call `ClientTunnel::as_single_circ()` to obtain a handle to the underlying `ClientCirc`. This is an opinionated design decision that goes against the plan from [!2790]. It stems from my thinking that it would make more sense to keep `ClientCirc`, than to merge it into `ClientTunnel`. If we merge the two, many functions will need become fallible and less ergonomic, because the user of `ClientTunnel` needs to know whether the `ClientTunnel` consists of a single-circuit or not. Providing (fallible) access to the underlying `ClientCirc` of the `ClientTunnel` seems simpler than the alternative. That being said, I am open to switching back to the original plan if this design turns out to be annoying to work with. [!2790]: https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2790
* Temporarily suppress mismatched_lifetime_syntaxes.Gabriela Moldovan2025-07-071-0/+1
| | | | See #2060.
* proto: Make TargetHop and HopLocation publicDavid Goulet2025-06-261-1/+1
| | | | | | | | | | | | | | | | | This is about to be used outside of tor-proto. It is part of the work to remove the use of HopNum outside tor-proto. The rules are: - Inbound requsest to the tor-proto crate, TargetHop must always be used. - Within tor-proto, TargetHop is resolved into a HopLocation which is more precise and based on the tunnel circuit(s). This is another piece that Conflux will require considering that a Tunnel might have multiple circuits in the future. Signed-off-by: David Goulet <[email protected]>
* *: suppress cognitive_complexity warnings from nightlyNick Mathewson2025-05-291-0/+3
| | | | | | | | | | | | | Apparently clippy nightly is better (or worse?) about detecting complex functions than before, so I'm suppressing these warnings where they occur. I have mixed feelings about these warnings: On the plus side, they really do help to detect functions that are twistier than they need to be. On the minus side, they get confused by tracing macros, and the "allows" do pile up. But on the plus side, those "allows" do provide a way to find functions that need to be refactored, and they are never uglier than the functions they decorate.
* protover, *: Add documentation about what "supported" means.Nick Mathewson2025-04-161-1/+2
|
* Add warnings about removing supported protocols.Nick Mathewson2025-04-161-0/+2
|
* New functions to report supported subprotocolsNick Mathewson2025-04-161-0/+42
| | | | | | | | | | | | | | | Part of #1849. Note that these functions are distributed across crates, so that if (in the future) we stop doing API breaks with every release, we will get the right outputs. Note also that these functions build the list of protocols out of specific symbolic features, rather than numbers: this makes it easier to avoid errors about "which feature was Relay=4 again", and easier to avoid accidentally referring to a protocol that doesn't exist, like "Consensus" (should be "Cons") or "HsDir" (case is wrong).
* tor-proto: Add a tunnel module.David Goulet2025-02-201-1/+2
| | | | | | | | | | | | | Move StreamTarget to the tunnel module and the circuit module. From now on streams will be implemented on tunnels, not circuits. This moves `StreamTarget` to the tunnel module. A future change will replace `ClientCirc` with `ClientTunnel` inside `StreamTarget`. This is mostly code motion, best reviewed with `--color-moved`. Signed-off-by: David Goulet <[email protected]>
* circmgr: Modify CircParameters for congestion controlDavid Goulet2025-01-161-0/+1
| | | | | | | | | | | | | | The congestion control parameters are created from the consensus parameters (netparams) and then put into the CircParameters object that is then passed down the tor-proto crate. Because different parameters are selected depending on the circuit type (onion vs exit vs sbws), a CircuitType enum is introduced for the sole purpose of being used to select the right parameters. Related #534 Signed-off-by: David Goulet <[email protected]>
* proto: Add generic objects for congestion controlDavid Goulet2025-01-161-0/+1
| | | | | | | | | | | | | | | | | | | | This commit adds the congestion window object, a round trip estimator (RTT) and a state enum. These 3 entities are used by congestion control in a generic way that is they are passed and used by any algorithm. At this commit, they are not used hence the allow deadcode attribute for now in order to minimize the build warnings. We also introduce the params.rs file containing the parameters, taken from consensus, used to configure these objects. They will be exposed to the tor-cirmgr crate to build the CircParameters. More will come. This also introduces the congestion/ directory that will contain more code in future commits. Related #534 Signed-off-by: David Goulet <[email protected]>
* clippy: deny `mod_module_files`Steven Engler2025-01-061-0/+1
| | | | | | Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
* add_warnings, *: Allow clippy::needless_lifetimesNick Mathewson2024-12-031-0/+1
| | | | | | | | 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.
* tor-proto: add a bench featureLionel Goffaux2024-11-061-0/+1
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 18:46:14 +0000