mirrors/arti.git/crates/tor-proto/src/stream/incoming.rs, branch arti-v1.9.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.9.02025-11-24T17:03:48Zproto: Fix a number of newly broken doc links2025-11-24T17:03:48ZGabriela Moldovangabi@torproject.org2025-11-20T14:37:17Zurn:sha1:56e0b40e5eb064881b6dd7ab95dd9b98ddaa6690proto: Move StreamComponents to top-level stream mod2025-11-24T16:47:11ZGabriela Moldovangabi@torproject.org2025-11-12T11:46:49Zurn:sha1:4f07434974b39ca6430a88465149e85f659c93d5proto: Move StreamReqInfo to stream module2025-11-24T16:31:55ZGabriela Moldovangabi@torproject.org2025-11-11T18:18:55Zurn:sha1:97da9b52b03d80db3ae8d9c5eb12daa098ecd048proto: Move IncomingStream* types to shared module2025-11-24T16:31:55ZGabriela Moldovangabi@torproject.org2025-10-29T13:37:45Zurn:sha1:2383dd0ae7fc89ece2a91a4bc80b8711b5227e37proto: Rename data cmd checkers to {Inbound,Outbound}DataCmdChecker2025-10-16T13:47:15ZGabriela Moldovangabi@torproject.org2025-10-16T12:48:06Zurn:sha1:12d2effc1410f8b59534ab883d727b6844dc14a7
The previous "incoming" terminology was rather ambiguous.
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3348#note_3275337
proto: Move IncomingDataCmdChecker to top-level stream module.2025-10-16T13:47:15ZGabriela Moldovangabi@torproject.org2025-09-30T00:04:25Zurn:sha1:869d1243cd3b17820fe234b3047e0e2fd8cc406b
This will be used by relays too (for validating incoming messages on
streams).
This is just code motion, so it's best reviewed with `--color-moved`.
proto: Move the `stream` module under `client` (breaking).2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:52:38Zurn:sha1:702e7276898d3f31e22033c5b64fea91703f3701
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`.2025-08-18T16:09:04ZGabriela Moldovangabi@torproject.org2025-08-18T15:14:43Zurn:sha1:1ee26f2168ee2dede8ab993ef57435334e9efabe
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.
Switch Cargo.toml files to edition 2024.2025-08-07T15:28:36ZNick Mathewsonnickm@torproject.org2025-08-06T01:19:58Zurn:sha1:77b0de43b8c67cdb81befe0680a3df43b6ad37bc
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.
proto: Move ClientCirc stream functions to ClientTunnel2025-08-05T18:23:02ZDavid Gouletdgoulet@torproject.org2025-05-28T15:03:00Zurn:sha1:98e5985cf71933aea065260b982ba4501f0f484c
In order to pull this off, some client => tunnel renaming needed to
happen including the comments.
The send_raw_msg() is an experimental and expert mode method that any
tunnel should have access to in order to be able to send whatever
message in whatever tunnel type.
No behavior changes.
Signed-off-by: David Goulet <dgoulet@torproject.org>