mirrors/arti.git/crates/tor-proto/src/channel, branch arti-v1.5.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.5.02025-08-28T10:54:48Zproto: Add a circuit module shared between client and relay impls.2025-08-28T10:54:48ZGabriela Moldovangabi@torproject.org2025-08-26T17:48:56Zurn:sha1:4ee5a4abcee895e79588888f6bc8eaa6963a6ba7
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: Only allow VERSIONS cell for the new handshake state2025-08-27T15:04:24ZDavid Gouletdgoulet@torproject.org2025-08-26T17:03:34Zurn:sha1:afe97476d39bfb3db7387ed073e4bad350ea3c7e
Due to this, it is not possible to get a VPADDING before because it
requires a link protocol version to decideon the encoding:
https://gitlab.torproject.org/tpo/core/torspec/-/issues/366
Signed-off-by: David Goulet <dgoulet@torproject.org>
proto: Remove the AUTHORIZE as a parsable cell2025-08-21T15:59:37ZDavid Gouletdgoulet@torproject.org2025-08-21T14:52:35Zurn:sha1:eabd0c0bfe703337e338403949721ce57c87f32e
The AUTHORIZE cell command is simply reserved but not defined. The tor
specification, at this point in time, is allowing such cell before the
handshake starts but it is very unclear on what ordering is allowed nor
how many can are allowed.
C-tor silents drop them like VPADDING and so clearly unused. Instead of
dealing with it, simply remove its support but keeping its reserved
number.
Signed-off-by: David Goulet <dgoulet@torproject.org>
proto: Add a channel handler comment and a fix2025-08-21T15:07:32ZDavid Gouletdgoulet@torproject.org2025-08-20T19:52:31Zurn:sha1:f6f3c99c4e530a688bd99eeec5323bb1ceb15df1
Signed-off-by: David Goulet <dgoulet@torproject.org>
proto: Return AUTHORIZE, VPADDING and VERSIONS at handshake2025-08-21T15:07:32ZDavid Gouletdgoulet@torproject.org2025-08-20T19:46:47Zurn:sha1:b758a3e844cdec9d78dc02237bb99d534ab1bfb7
When starting a handshake, we were only expecting a VERSIONS which is
not what the protocol say. An AUTHORIZE and VPADDING can arrive before a
VERSIONS.
Signed-off-by: David Goulet <dgoulet@torproject.org>
proto: Allow padding in all channel message sets2025-08-21T15:07:32ZDavid Gouletdgoulet@torproject.org2025-08-20T19:06:15Zurn:sha1:7e3b3397337ded7c0443b9548c9aac2c60bc1a23
First of all, VPADDING has been added in link protocol version 3 so it
was missing from v4.
Second, after closely looking at C-tor and the spec, it appears that we
allow VPADDING at any point on a channel which should simply be silently
dropped. Any number in any order.
Third, couple sets were missing the PADDING cell which is only allowed
on an open channel.
Signed-off-by: David Goulet <dgoulet@torproject.org>
tor-proto: simplify some match statements2025-08-20T19:34:41ZSteven Engleropara@torproject.org2025-08-20T19:34:41Zurn:sha1:8e1fd121868cec1469ceeb9a12968e56386a5bd0proto: Change (crate) to (super) for all objects in msg.rs2025-08-20T17:22:16ZDavid Gouletdgoulet@torproject.org2025-08-20T15:34:47Zurn:sha1:0a8bb1de6350a2ba7ba7b59c305a9b3181dd052a
Signed-off-by: David Goulet <dgoulet@torproject.org>
proto: Cleanup allow(unused)2025-08-20T17:22:16ZDavid Gouletdgoulet@torproject.org2025-08-14T14:08:49Zurn:sha1:6d037f809446d624e63888f4ceb00041cf2671eb
Signed-off-by: David Goulet <dgoulet@torproject.org>
proto: Unit tests for channel handler2025-08-20T17:22:16ZDavid Gouletdgoulet@torproject.org2024-10-09T18:22:06Zurn:sha1:41a2b3d07176f38bc1174dae1abcf8aa9b5aa5e6
Signed-off-by: David Goulet <dgoulet@torproject.org>