mirrors/arti.git/crates/tor-cell/src/relaycell.rs, branch arti-v2.5.0mirror of https://gitlab.torproject.org/tpo/core/arti
http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v2.5.02025-09-15T19:45:38Ztor-cell: add pub `PAYLOAD_MAX_SIZE_{ALL,ANY}`2025-09-15T19:45:38ZSteven Engleropara@torproject.org2025-09-15T18:07:38Zurn:sha1:a45cc84460cf577d223882a6ec704a23a934bb96padding: Report when we have received padding or data.2025-09-02T19:17:54ZNick Mathewsonnickm@torproject.org2025-09-02T19:17:54Zurn:sha1:6bf8b425f7ed810b64cae811ac5409b5f107aa24
(This was so much easier than reporting on the send side.)
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.
tor-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:1dbe3698641ee1836cf24e497919187c47ae8148