summaryrefslogtreecommitdiff
path: root/crates/tor-cell/src
Commit message (Collapse)AuthorAgeFilesLines
* 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-183-0/+216
| | | | | | | This adds support for encoding and decoding `RELAY_CONFLUX_LINK`, `RELAY_CONFLUX_LINKED`, and `RELAY_CONFLUX_SWITCH` cells. Closes #1852
* tor-cell: Add conflux RelayCmds.Gabriela Moldovan2025-02-181-0/+13
| | | | Part of #1852
* Merge branch 'mod-module-files' into 'main'Nick Mathewson2025-01-071-0/+1
|\ | | | | | | | | clippy: deny `mod_module_files` See merge request tpo/core/arti!2689
| * clippy: deny `mod_module_files`Steven Engler2025-01-061-0/+1
| | | | | | | | | | | | Denies 'mod.rs' files for consistency. https://rust-lang.github.io/rust-clippy/master/index.html#mod_module_files
* | fix: fix typosDimitris Apostolou2025-01-061-1/+1
|/
* add_warnings, *: Allow clippy::needless_lifetimesNick Mathewson2024-12-031-0/+1
| | | | | | | | In 1.83, this warning triggers on many of our crates. We're thinking of fixing them all, but for now, we're going to disable the warning. This is part of #1765.
* 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]>
* tor-hspow: Big refactor, dissolve this crateWesley Aptekar-Cassels2024-10-093-48/+61
| | | | | | | | | | | | | | | | | My previous strategy here was to try and centralize hspow in one crate, writing it like a self-contained feature. That introduced friction in the data types, prompting the use of simplistic types at the netdoc/cell layers and full-featured types in the optional modules. This changes tactics, dissolving the low-level parts of tor-hspow into tor-hscrypto and the high-level parts into hsclient/hsservice. Full featured types are used everywhere now, but the tradeoff is that compile-time configurability is a lot more pervasive. Anything that knows about PoW types at all needs to be fully configured out. I took this opportunity to try a more complete set of crate features, allowing users to configure individual PoW schemes. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-cell: Support encoding proofs-of-work in intro_payloadWesley Aptekar-Cassels2024-10-093-4/+111
| | | | | | | | | Like parameters, PoW solutions are versioned to account for multiple algorithms over time. A single solution of a specific version may accompany an INTRO1/2 as part of the encrypted extensions section. Its encoding may depend on the version. Co-authored-by: Micah Elizabeth Scott <[email protected]>
* tor-memquota: Explain choice of boundsIan Jackson2024-10-021-0/+2
| | | | | Properted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2459#note_3086841
* Revert "tor-cell: Use HasMemoryCostStructural, rather than Copy"Ian Jackson2024-10-021-1/+2
| | | | This reverts commit def8810156f8c2bf8f18ef9ad75a61601f6fea78.
* tor-cell: Use HasMemoryCostStructural, rather than CopyIan Jackson2024-10-021-2/+1
| | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/2459#note_3086839
* Some HasMemoryCost impls in tor-cellIan Jackson2024-10-028-62/+162
|
* tor-bytes: Only report Truncated for errors at the outer levelIan Jackson2024-09-111-3/+1
| | | | | | | | | | | This is item 1 from https://gitlab.torproject.org/tpo/core/arti/-/issues/1614#note_3074562 and the alternative to item 2 presented in the 2nd half of https://gitlab.torproject.org/tpo/core/arti/-/issues/1614#note_3074648 (Item 3 was done earlier, but now we change the behaviour.) Fixes #1614.
* tor-bytes: Error: provide and call Error::incomplete_errorIan Jackson2024-09-111-0/+1
| | | | | | | | | | | | | | | | | | | We introduce the new constructor and call it at the error generation sites. But there is still not yet any functional change. Change the type of Truncated's field to be Sensitive. The original reason for not doing this no longer applies, since we don't generally want to open-code construction of this variant. Conveniently, changing the type means we get to find all the sites where one *is* constructed and adjust them. In reader.rs and tor-proto we can just call incomplete_error. In tor-cell, there's a call site where we previously provided an underestimate, and where the Reader isn't available. We adjust that ad-hoc but this is fine because the error variant will change. (relaycell is using a Reader from from_slice.)
* tor-cell: No longer treat certain tor-bytes errors as EK::InternalIan Jackson2024-09-111-5/+0
| | | | | | | | | I don't see a justification for this. Rather than updating this code for the new distinction between what is going to be Incomplete (ie, our buffer didn't contain enough data and we want to read more) and MissingData, I think we can just do away with it. Perhaps in the future, tor_bytes::Error would implement HasKind.
* Change tor_bytes::Readable name to `b` in many placesIan Jackson2024-09-111-15/+15
| | | | | | | | | | | | | | | The codebase uses `r` sometimes and `b` at other times. Making this consistent makes widespread changes easier, and is clearer for humans. I think `b` is better than `r` because `r` might be "return". It is indeed used that way in a couple of places in reader.rs, even. I haven't changed *everywhere*, just Readable impls (where `r` is particularly likely to be "return value") and occurrences in tor-bytes. No functional change.
* tor-bytes: Add a deficit field to Error::TruncatedIan Jackson2024-09-102-2/+3
| | | | This will allow us to fix #1592, but it doesn't do so yet.
* tor-proto::circuit::StreamMap: Use StreamPollSetJim Newsome2024-08-011-1/+1
| | | | | | | | | | | | | | | | | | | | * Refactors `StreamMap` to use `StreamPollSet` to manage its receivers for mpsc streams. * Extends `StreamMap` to support iterating only over streams that have a pending outgoing message, and in round-robin order. * Updates `circuit::reactor::Reactor` to use this functionality. It now iterates only over streams that have a ready outgoing message, and only actually "pops" a message that is ready to be sent. This mildly simplifies the circuit reactor, but more importantly clears the way to: * Remove the "outbound queue" of messages that were pulled from stream channels but that we couldn't send yet due to congestion control. * Support opportunistic packing when preparing to send a relay message. (proposal 340). * Refactor the circuit reactor's `run_once` into futures that we can `select!` over.
* Fix clippy::doc_lazy_continuationIan Jackson2024-07-081-4/+4
|
* Fix indentation from last commit.Nick Mathewson2024-05-071-33/+33
|
* tor-cell: Allow unuexpected_cfgs in restricted macro.Nick Mathewson2024-05-071-0/+7
| | | | (We need this to permit our usage of our $omit_from hack.)
* Re-run maint/add_warning.Nick Mathewson2024-05-061-2/+2
| | | | This commit is automatically generated.
* Use uXX::MAX in place of std::uXX::MAXNick Mathewson2024-04-223-4/+4
| | | | | | The old code produced a warning from clippy nightly; we may as well update to use the new associated consts. (They've been there since Rust 1.4x.)
* Fix compilation for relaymsg fuzzerNick Mathewson2024-04-021-0/+2
| | | | This broke when we changed the relaymsg api.
* Add and use RelayCellFormatTraitJim Newsome2024-03-201-24/+39
| | | | | | This lets us paramaterize types and functions by a particular relay cell format. We use this e.g. to statically parameterize the cell crypto functions, thereby removing some run-time branching in the hot path.
* RelayCellBody: generalize over RelayCellFormatJim Newsome2024-03-201-0/+26
| | | | | Different formats will use different ranges for the `recognized` and `digest` fields.
* Run maint/add_warning.Nick Mathewson2024-03-132-0/+2
|
* Remove RelayMsgOuter::decode_from_readerJim Newsome2024-03-121-11/+3
| | | | | | The semantics of such a function that supports both the legacy V0 format and the V1 packing and fragmentation format are a bit tricky. Since it's not used outside of its module, we can simply remove it.
* relay-cell: Update relay cell decoding API for prop340Jim Newsome2024-03-121-23/+225
| | | | | | | | | | | Prop 340: https://spec.torproject.org/proposals/340-packed-and-fragmented.html This updates the decoding API to support multiple versions of the relay cell encoding, including the new encoding proposed in prop340 that supports relay message packing and fragmentation. This commit doesn't actually add support for that new encoding yet.
* Rename UnparsedRelayCell -> UnparsedRelayMsgJim Newsome2024-03-121-7/+4
| | | | | For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
* Fix typos in doc commentsTobias Stoeckmann2024-03-061-1/+1
|
* deny clippy::unchecked_duration_subtractiontrinity-1686a2024-02-291-0/+1
|
* tor-cell: impl Eq, PartialEq, Hash for est_intro::DosParamsIan Jackson2024-02-211-1/+1
| | | | | | We only need Eq and PartialEq but given those we should have Hash too. (We're going to want to be able to compare parameters for equality.)
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-131-3/+28
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* tor_cell: Reject empty DATA messagesNick Mathewson2024-02-131-0/+3
| | | | | | | | | | | If we don't reject these, they are a way to inject an undetected traffic signal. (This is LOW severity, since we only accept DATA when a stream is open, since DATA messages are rate-limited, and since using length==1 is nearly as effective.) Closes #1269. This is TROVE-2024-001.
* educe: Use std's default for enums where default variant is unitIan Jackson2024-02-121-4/+2
| | | | | | | | | | | | | Since Rust 1.66, std's default works properly for enums, provided that the default variant is a unit. Review all uses of `#[educe(default)]` on enums and replace them with std where possible, which is most of them. In 1.66 and later, std's `#[derive(Default)]` doesn't infer any generic bounds on the derived impl, where it's an enum - since the unit variant can always be constructed. So this change doesn't add any generic bounds and is not API-visible.
* Fix typosDimitris Apostolou2024-01-082-2/+2
|
* tor-cell: Fix ambitious certtypeEmil Engler2023-12-281-1/+2
| | | | | | | When using the `arti-client` crate in other contexes, the Rust compiler sometimes has difficulties with determining the current type in this particular case, due to a collision with the popular serde json crate, which also provides an implementation for converting u8.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 02:03:39 +0000