aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-cell/src
Commit message (Collapse)AuthorAgeFilesLines
...
| * 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.
* tor-cell: Stop using deprecated name in doctestNick Mathewson2023-12-141-2/+2
|
* Add deprecated aliases for old RelayCell namesNick Mathewson2023-12-141-0/+8
| | | | | We should remove these once we do our final renaming here, but for now we may as well avoid a breaking change.
* Fix documentation that referred to RelayCell.Nick Mathewson2023-12-141-9/+4
|
* Fix documentation for {Any}RelayMsgOuterNick Mathewson2023-12-141-3/+7
|
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-141-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | This commit is pure renaming, done automatically with rust-analyzer. Comment fixes and other cleanups will be in the subsequent commits. We're doing this renaming because we need a name for the combination of a `RelayMsg` and an `Option<StreamId>` that we use when we have a `RelayMsg` we intend to route to a given stream or circuit internally. Previously we called this a `RelayCell`, but that name was already somewhat inaccurate, and will become _very_ inaccurate with the arrival of prop340, which breaksthe 1:1 relationship between relay cells and relay messages. (If we didn't do this renaming now, we'd soon be making the relationship between `UnparsedRelayCell`and `RelayCell` many-to-many, which would be ridiculous and confusing.) The `RelayMsgOuter` name is a placeholder: We expect that we'll want to rename this type, and may also want to rename `RelayMsg`, and unify our vocabulary in other areas too. But such a renaming will have to wait for a larger discussion affecting the specifications, so that we can use the same vocabulary everywhere.
* tor-cell: Remove a now-unneeded allow(unused).Nick Mathewson2023-12-121-1/+0
|
* NtorV3Extension set encoding/decoding: include n_extensionsJim Newsome2023-12-071-7/+17
| | | | | | | | | | An encoded set of extensions in the ntorv3 handshake includes a header with the number of extensions. This change adds that header. It also changes `write_many_onto` to take a slice instead of an iterator, since we need to know the number of extensions up-front. In principle we could take a clonable iterator instead and use Iterator::count, but it's probably not worth the extra complexity.
* Convert to the latest versions of dalek-cryptographyNick Mathewson2023-11-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The main changes that we have to adjust for are as follows: * In x25519-dalek: * `StaticSecret` is now behind a feature. * `StaticSecret::new` is deprecated in favor of `StaticSecret::random_from_rng`. * StaticSecret no longer does its own clamping. * In ed25519-dalek: * `SecretKey` has (in effect) been renamed to `SigningKey`. The name `SecretKey` is now an alias for `[u8; 32]`. * `SigningKey` is effectively a keypair, since it contains a public key as well. * `PublicKey` has been renamed to `VerifyingKey`. * The functions to extract a signing key and verifying key have been renamed as you might expect. * `ExpandedSecretKey` has been moved to `hasmat` and no longer implements `sign`. * `ExpanededSecretKey` now has as its elements a scalar and a hash prefix. * Various functions that took `&[u8]` now take `&[u8; N]`. * We no longer need a wrapper for older versions of rand. There is a single test in tor-keymgr that does not pass. I've marked it as ignore for now, in hopes that @gabi-250 can help me figure it out. This closes #808. There are several changes I want to make before we merge, however. They are marked with TODO DALEK.
* Use HandshakeType in Extend2 and CircuitExtender::beginJim Newsome2023-11-271-6/+12
|
* Add more reference links.Nick Mathewson2023-11-201-1/+5
|
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 23:36:14 +0000