mirrors/arti.git/crates/tor-cell/src/relaycell.rs, branch arti-v1.4.6mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.4.62025-07-15T06:04:44Ztor-cell: change `UnparsedRelayMsg::data_len`2025-07-15T06:04:44ZSteven Engleropara@torproject.org2025-07-15T03:50:51Zurn:sha1:d499af464198520e0b4115d624b1cf53929d0024
It now performs some validation and can return a `Result`.
We perform validation here since different cell formats may have
different maximum data lengths in the future, and `UnparsedRelayMsg`
doesn't expose the cell format so it's difficult to perform this
validation at a higher layer.
tor-cell: remove `flowctl-cc` feature and make XON/XOFF cells stable2025-07-15T05:33:18ZSteven Engleropara@torproject.org2025-07-15T05:27:21Zurn:sha1:676dbdb43f2a930b7dc89d2a6275338064fd37bf
I don't see any further changes being needed for these types, and it
simplifies a lot of future code in tor-proto that uses these types.
tor-cell: fix incorrect XON/XOFF cell command integers2025-06-23T15:11:20ZSteven Engleropara@torproject.org2025-06-23T15:11:20Zurn:sha1:298c4688837e19be22c40470cd1fed940afa1e31tor-cell: add `Xon`/`Xoff` cells2025-06-09T14:09:20ZSteven Engleropara@torproject.org2025-06-09T14:01:28Zurn:sha1:2d3f0918ab866ef25fe259c6648e208a01865a93cell: move ExtList module out of hs module.2025-05-07T12:39:33ZNick Mathewsonnickm@torproject.org2025-04-30T14:14:59Zurn:sha1:c2d455628b5a6cea4c6af75f72f4664b925f7653
We're going to use it for ntorv3 extensions as well.
proto, cell: Remove RelayCellFormatTrait.2025-05-06T22:34:17ZNick Mathewsonnickm@torproject.org2025-04-30T00:59:07Zurn:sha1:297aa8027f7528605fe5bf2097f3474d9ba3eef9
The purpose of the trait was to parameterize the tor1 cell crypto
on the different possible relay cell layouts.
It made sense to have this trait when we thought we would implement
the new cell layout for prop340 (packed-and-fragmented) well before
we implemented CGO.
But it now appears all but certain that CGO will land long before
we make any more headway on prop340. Therefore,
it doesn't make sense to carry the ability to customize `tor1`
for other relay cell layouts.
Removing this trait saves a fair bit of complexity.
tor-cell: optimize slice indexing2025-05-01T02:01:43ZSteven Engleropara@torproject.org2025-05-01T01:27:04Zurn:sha1:1dbe3698641ee1836cf24e497919187c47ae8148tor-cell: rename `STREAM_ID_OFFSET` to `STREAM_ID_OFFSET_V0`2025-05-01T01:51:55ZSteven Engleropara@torproject.org2025-05-01T01:01:42Zurn:sha1:6f5963d21f3d66ae18a24048eb080d2be8d627dator-cell: add `UnparsedRelayMsg::data_len`2025-05-01T01:51:55ZSteven Engleropara@torproject.org2025-04-30T17:49:21Zurn:sha1:163dc9d6dd7f167869c54f6f2d95cf04ca2af58dcell: simpler (?) approach to StreamIdReq2025-04-16T14:58:49ZNick Mathewsonnickm@torproject.org2025-04-16T12:33:23Zurn:sha1:deb42f5d25ce8a40dbae2f118e976ebab9def7b1
Instead of having a StreamIdReq that indicates
"None in V1, Any in V0", take an optional RelayCellFormat
as an argument.