mirrors/arti.git/crates/tor-cell/semver.md, 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.02026-06-24T17:09:18Ztor-cell: remove `derive_more::Into` for `RelayEarly`2026-06-24T17:09:18ZSteven Engleropara@torproject.org2026-06-24T16:49:14Zurn:sha1:6c322cb64c54538efd486055f050dd924e9ff357
We don't use this anymore, and it can lead to subtle bugs since we lose
the original channel message command.
Remove semver.md files2025-08-28T21:28:12ZNick Mathewsonnickm@torproject.org2025-08-28T21:28:12Zurn:sha1:518a491984cbd7f4239501dbb8a00d57dfc7a195proto: 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>
tor-hsservice: Change capping of PoW effort.2025-08-13T18:43:05ZWesley Aptekar-Casselsme@wesleyac.com2025-08-13T18:20:11Zurn:sha1:8e9e5a2f6ff20360816896b971408e8bf1b5c7ea
This caps the PoW effort during sorting, rather than at intake.
This allows us to record efforts that are capped in our metrics
histogram while only recording metrics after the PoW solve has actually
been verified.
Remove semver.md files, post-release.2025-08-05T18:12:52ZIan Jacksonijackson@chiark.greenend.org.uk2025-08-05T18:12:52Zurn:sha1:ea4063c9cf01d40c15f0380607ae35b5f0d4ce5btor-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.
release: Delete semver.md files after release.2025-06-05T13:45:22ZAlexander Hansen Færøyahf@torproject.org2025-06-05T13:45:22Zurn:sha1:a59953da8d68cbf8ffdc8711e3fc5ec3bba77ae4cell,proto: Split request/response extensions into seprate types2025-05-07T12:44:59ZNick Mathewsonnickm@torproject.org2025-04-30T17:27:58Zurn:sha1:ff9c3478d2aac678e4ad27712fd65b1ce296d423
Implements part of proposal 358.
Rename NtorV3Extension to CircRequestExt2025-05-07T12:41:39ZNick Mathewsonnickm@torproject.org2025-04-30T16:05:45Zurn:sha1:70aab0213f42b14ff8dfa02c22a2cf615709ed9c
This type will, because of prop358, be shared by ntorv3,
hs-ntor, and probably other future handshakes.
There will also be a CircResponseExt type.