summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src/relaycell
Commit message (Collapse)AuthorAgeFilesLines
* cell: Add an accessor for the linkspecs of an EXTEND2Gabriela Moldovan2026-02-051-0/+5
|
* Remove unnecessary `doc(cfg(...))` attributesNeel Chauhan2025-12-041-3/+0
| | | | | | | | | Fixes part of #2193. (Edits from nickm: I selected the cases here that I could verify were correct from immediate context.) Edited-by: Nick Mathewson <[email protected]>
* cell: Add missing docs to internal macroGabriela Moldovan2025-12-011-0/+2
|
* Merge branch 'bug2172' into 'main'Nick Mathewson2025-11-241-1/+1
|\ | | | | | | | | | | | | tor-llcrypto: Stop deriving Deref in CtByteArray Closes #2172 See merge request tpo/core/arti!3432
| * tor-llcrypto: Stop deriving Deref in CtByteArrayNeel Chauhan2025-11-241-1/+1
| |
* | Fix name of clippy lint to unchecked_time_subtraction (2)Ian Jackson2025-11-062-2/+2
| | | | | | | | Run maint/add_warning
* | Decorate a use with an allowIan Jackson2025-11-061-0/+1
|/ | | | | | | This seems to depend on cfgs. As I say in #1060, I don't think precise cfg decoration of imports is sensible. Also, it shouldn't be my job to fix whatever this is...
* tor-cell: add `Display` impl for `XonKbpsEwma`Steven Engler2025-09-221-0/+9
|
* tor-hsservice: Change capping of PoW effort.Wesley Aptekar-Cassels2025-08-131-10/+0
| | | | | | | | 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.
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-076-12/+12
| | | | | | | | | | | | | | 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.
* Merge branch 'msrv-fixes' into 'main'Nick Mathewson2025-08-051-5/+11
|\ | | | | | | | | Resolve a few issues that had been waiting for an MSRV update. See merge request tpo/core/arti!3129
| * tor-cell: Check strictly-ascending property more efficientlyNick Mathewson2025-08-051-5/+11
| | | | | | | | | | | | I had been planning to use `[]::is_sorted` here, once we had MSRV >= 1.82, but it turns out that we wanted strictly ascending sequence, whereas `is_sorted` checks for a non-descreasing sequence.
* | tor-cell: Add ProofOfWorkV1::cap_effort function.Wesley Aptekar-Cassels2025-08-051-0/+10
|/
* tor-cell: add `FlowCtrlVersion::V0`Steven Engler2025-07-161-0/+3
|
* tor-cell: remove `flowctl-cc` feature and make XON/XOFF cells stableSteven Engler2025-07-151-7/+1
| | | | | 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: add a const constructor for `FlowCtrlVersion`Steven Engler2025-07-151-7/+14
|
* tor-cell: add `Xon`/`Xoff` cellsSteven Engler2025-06-092-0/+175
|
* arti, cell, dirclient: Use expect instead of unwrap.Nick Mathewson2025-05-291-2/+3
| | | | | | Clippy nightly detects this problem, though earlier clippy verisons haven't. The common element here is applying unwrap() to the result from a write!().
* cell: fix warning from nightly about unused function.Nick Mathewson2025-05-291-0/+1
|
* Add methods for getting proof-of-work extension from intro request.Wesley Aptekar-Cassels2025-05-272-1/+10
|
* cell: Teach extlist definition macro to make conditional extensionsNick Mathewson2025-05-072-1/+7
| | | | | We need the macro to propagate only certain #[meta] values to all places where a case is used.
* cell: Implement SubprotocolRequest extension from prop346.Nick Mathewson2025-05-071-1/+138
| | | | Part of #1945.
* cell: Unify HS-ntor and ntor-v3 extensions.Nick Mathewson2025-05-076-32/+22
| | | | | | Implements proposal 358. Closes #1946.
* cell,proto: Split request/response extensions into seprate typesNick Mathewson2025-05-071-21/+44
| | | | Implements part of proposal 358.
* cell: Use ExtList to implement CircRequestExt.Nick Mathewson2025-05-072-105/+100
| | | | This required some renaming, so that the types and their codes matched.
* Rename NtorV3Extension to CircRequestExtNick Mathewson2025-05-071-18/+19
| | | | | | | This type will, because of prop358, be shared by ntorv3, hs-ntor, and probably other future handshakes. There will also be a CircResponseExt type.
* cell: Make decl_extension_group macro more self-contained.Nick Mathewson2025-05-074-14/+21
| | | | Previously it required the caller to import a whole bunch of stuff.
* cell: Clarify documentation in extlist.rs.Nick Mathewson2025-05-071-11/+10
| | | | It is no longer hs only.
* cell: move ExtList module out of hs module.Nick Mathewson2025-05-075-7/+5
| | | | We're going to use it for ntorv3 extensions as well.
* proto: Use SendmeTag in place of CircTagNick Mathewson2025-05-061-4/+2
| | | | | This doesn't make much change yet, but does save us an allocation when handling SENDMEs.
* tor-cell: define a new SendmeTag typeNick Mathewson2025-05-061-9/+149
| | | | | | | | | | | | | | | | This is a more efficient representation for the tag on an authenticated SENDME message: it comes in at 21 bytes. Previously, we used Vec<u8>, which has 24 bytes of overhead (on a 64 bit system), plus malloc overhead, plus 20 bytes of allocated tag. We had a similar type to this as `tor_proto::congestion::sendme::CircTag`, but it could only accomodate 20-byte values. I don't expect that we will have enough of these simultaneously that the memory savings will matter, but the allocation savings could be significant.
* cell, proto: Use correct Data sizes for v1 relay cellsNick Mathewson2025-04-162-7/+29
| | | | | | | | | | | | Since v1 cells have a longer tag, they can fit less data into a single cell. Ah well, that's the cost of improved security. The code in data.rs is a little wonky, in that it currently requires its buffer to be exactly the maximum size for a data cell. We have a TODO about fixing that in the future, but for now I've moved it to use a boxed slice rather than a boxed array. Part of #1944.
* cell: Remove the deprecated Data::split_from().Nick Mathewson2025-04-161-14/+0
|
* Note some places where we need updates for #1944.Nick Mathewson2025-04-162-0/+8
| | | | (Also note a couple of other CGO-related issues)
* tor-cell: Make conflux::V1Nonce opaque, add constructor.Gabriela Moldovan2025-04-081-7/+30
| | | | We will soon need to construct `V1Nonce`s.
* tor-cell: Copy ConfluxSwitch::seqno in getter.Gabriela Moldovan2025-04-081-0/+1
| | | | `u32` is `Copy`, so the getter doesn't need to return a ref.
* Merge branch 'interface-abstraction-of-the-daleks' into 'main'Nick Mathewson2025-03-181-1/+0
|\ | | | | | | | | Wrap x25519-dalek and ed25519-dalek types. See merge request tpo/core/arti!2868
| * Wrap ed25519-dalek types.Nick Mathewson2025-03-181-1/+0
| | | | | | | | | | | | | | | | | | | | | | With this change, we'll no longer need to expose the types from dalek-cryptography as part of our API, and we'll have more freedom to switch ed25519 implementations, or to upgrade to a newer `rand` ahead of their schedule. Unlike with x25519-dalek, I had to tweak the API a bit: There's no way to get a &PublicKey out of a Keypair now, and implementing the old ed25519-dalek traits seemed unnecessary.
* | tor-cell: Implement RelayMsg for all conflux message types.Gabriela Moldovan2025-03-171-1/+1
| |
* | tor-cell: Add setters for the V1LinkPayload seqnos.Gabriela Moldovan2025-03-131-0/+10
| |
* | tor-cell: Make V1_LINK_NONCE_LEN pub.Gabriela Moldovan2025-03-131-1/+1
| |
* | tor-cell: Add constructors for the conflux cell types.Gabriela Moldovan2025-03-131-0/+46
| | | | | | | | We will soon need these in the circuit reactor.
* | tor-cell: Add type alias for the V1LinkPayload nonce.Gabriela Moldovan2025-03-131-1/+4
|/
* tor-cell: Add encodable conflux relay message types.Gabriela Moldovan2025-02-182-0/+214
| | | | | | | This adds support for encoding and decoding `RELAY_CONFLUX_LINK`, `RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells. Closes #1852
* fix: fix typosDimitris Apostolou2025-01-061-1/+1
|
* PoW: Consolidate feature flags into a single flag.Wesley Aptekar-Cassels2024-11-251-1/+1
| | | | | | | | | | | | | | | | | This replaces the hs-pow, hs-pow-full, hs-pow-v1, pow-v1, and pow-full features with a single hs-pow-full feature. It's possible that in the future we will want to split different schemes into different features, but we can do that when it comes up. For now, having this as a single flag makes it clearer what's going on, since the previous thing was not actually expressive enough to capture some things we care about (like "at least one pow scheme is enabled" that works in a future-compatible way). This change is not semver breaking since it's a experimental feature. Related: #1751
* tor-cell: add clippy allowsSteven Engler2024-11-201-0/+1
|
* hs-pow: Clarify a confusing comment in ProofOfWorkV1.Wesley Aptekar-Cassels2024-10-091-1/+1
| | | | Co-authored-by: Micah Elizabeth Scott <[email protected]>
* hs-pow: Rename seed to seed_head.Wesley Aptekar-Cassels2024-10-091-3/+3
| | | | | | Feedback from the hs-pow code review, the internal seed heading member should be seed_head instead of seed, for consistency. Very low impact change since the field name is not public.
* hs-pow: Refactor to prefer stub types rather than cfg sprawl.Wesley Aptekar-Cassels2024-10-094-29/+90
| | | | | | | | | | | | | | | | | | | | | | In this design, the thin multiplexing layer between PoW types is always available when onion services are in use, but the specific pow schemes (and their dependency libraries) are gated by crate features everywhere. There are now no new cfg() gates. When the pow-v1 scheme is disabled, we can parse `pow-params v1` lines into an empty type (so clients know a PoW scheme exists that might be supported if they were configured differently). We currently don't save the contents of unknown hsdesc items. On the relaycell side, the hs ext module already sets a strong precedent for keeping unrecognized data as a byte vec, and it doesn't provide a good way to signal soft parse errors like unrecognized optional extensions. There, the `v1` type is completely optional, and services lacking a pow scheme suggested by a client would see one of these 'unrecognized' blobs. This isn't necessarily helpful but it fits the rest of the design. Co-authored-by: Micah Elizabeth Scott <[email protected]>