summaryrefslogtreecommitdiff
path: root/crates/tor-proto
Commit message (Collapse)AuthorAgeFilesLines
...
* Clean up match statement a little.Nick Mathewson2024-03-261-7/+7
|
* We now need circuit::handshake to exist unconditionally.Nick Mathewson2024-03-262-2/+15
|
* Refactor the logic for constructing crypt layers.Nick Mathewson2024-03-263-77/+95
| | | | | | | | | | | The key insights here are: - That relay cell format and crypto protocols aren't orthogonal: Once we have GCO, it will require V1. - That we only need the actual functions for layer construction to be generic; we don't need to proliferate generic parameters everywhere. - That the circuit::handshake module already does most of what we want.
* Add and use RelayCellFormatTraitJim Newsome2024-03-204-113/+129
| | | | | | 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.
* Propagate RelayCellFormat selection up to where format decisions will be madeJim Newsome2024-03-204-30/+83
|
* Paramaterize layer crypto objects by cell formatJim Newsome2024-03-203-25/+49
|
* RelayCellBody: generalize over RelayCellFormatJim Newsome2024-03-201-13/+31
| | | | | Different formats will use different ranges for the `recognized` and `digest` fields.
* Add tor_proto::util::ct::is_zeroJim Newsome2024-03-201-0/+25
|
* RelayCellBody::is_recognized: improve doc commentNick Mathewson2024-03-201-1/+7
|
* RelayCellFormat::recognized -> is_recognizedJim Newsome2024-03-201-3/+3
|
* Run maint/add_warning.Nick Mathewson2024-03-1317-0/+17
|
* relay-cell: Update relay cell decoding API for prop340Jim Newsome2024-03-125-28/+104
| | | | | | | | | | | 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-1210-39/+39
| | | | | For consistency with the terminology proposed in https://gitlab.torproject.org/tpo/core/torspec/-/issues/253
* Fix typos in documentationTobias Stoeckmann2024-03-061-1/+1
|
* Fix typos in doc commentsTobias Stoeckmann2024-03-061-1/+1
|
* Merge branch 'remove-semver' into 'main'Ian Jackson2024-03-051-1/+0
|\ | | | | | | | | Remove semver.md files from arti 1.2.0 release. See merge request tpo/core/arti!2022
| * Remove semver.md files from arti 1.2.0 release.Gabriela Moldovan2024-03-041-1/+0
| |
* | Merge branch 'deny-unchecked-duration-substraction' into 'main'Ian Jackson2024-03-051-0/+1
|\ \ | |/ |/| | | | | | | | | deny clippy::unchecked_duration_subtraction Closes #1304 See merge request tpo/core/arti!2008
| * deny clippy::unchecked_duration_subtractiontrinity-1686a2024-02-291-0/+1
| |
* | tor-cert: Bump minor version.Gabriela Moldovan2024-03-041-1/+1
| | | | | | | | | | | | | | | | | | | | We bumped the minor version of `tor_checkable`, which is used in the `tor-cell` public APIs (e.g. `Ed25519Cert` implements `tor_checkable::Timebound`, using `tor_checkable::TimeValidityError` as its error type). This bumps the minor version of `tor-cert` (including for its dependents).
* | Bump the minor version, for crates with breaking changes.Gabriela Moldovan2024-03-041-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | APIs were broken in these pre-1.0.0 crates: ``` tor-keymgr tor-config tor-checkable tor-circmgr tor-dirmgr tor-hsclient tor-hsservice tor-hsrproxy ``` Done with: ``` cargo set-version --bump minor -p tor-keymgr cargo set-version --bump minor -p tor-config cargo set-version --bump minor -p tor-checkable cargo set-version --bump minor -p tor-circmgr cargo set-version --bump minor -p tor-dirmgr cargo set-version --bump minor -p tor-hsclient cargo set-version --bump minor -p tor-hsservice cargo set-version --bump minor -p tor-hsrproxy ```
* | Bump patchlevel of pre-1.0.0 crates with new APIs.Gabriela Moldovan2024-03-041-3/+3
|/ | | | | | | | | | | | | | | | | | | | APIs were added: ``` tor-units tor-cell tor-proto tor-netdir arti-client ``` Done with: ``` cargo set-version --bump patch -p tor-units cargo set-version --bump patch -p tor-cell cargo set-version --bump patch -p tor-proto cargo set-version --bump patch -p tor-netdir cargo set-version --bump patch -p arti-client ```
* tor-proto: Note the addition of PendingClientCirc::peek_unique_id in semver.md.Gabriela Moldovan2024-02-281-1/+1
|
* tor-proto: Add function for peeking at pending circ unique ID.Gabriela Moldovan2024-02-271-0/+5
| | | | | | | | | `tor_circmgr::Error::Protocol` will soon include an optional `UniqId`. Since `Protocol` errors can be caused by pending circuits, we need to be able to peek at their `UniqId`. Part of #1297
* tor-circmgr: Add a helper for displaying optional UniqIds.Gabriela Moldovan2024-02-272-1/+18
| | | | | | | | Some of the `tor_circmgr::Error` variants will include the `UniqId` of the corresponding circuit, so we'll need to be able to display it without the `Circ ` prefix. Part of #1297
* tor_cell: never construct empty DATA messages.Nick Mathewson2024-02-132-11/+11
| | | | | | | We never actually constructed these before, but now we enforce it at the API level. Part of #1269.
* Bump minor versionsIan Jackson2024-02-051-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Bump the minor version of these crates, and update the in-tree dependencies. Recently published as fresh crates, let's just assume there are breaking changes: fslock-guard test-temp-dir Breaking API change affecting many many downstream crates: tor-rtcompat Downstream crates which we're (conservatively) assuming have tor-rtcompat types in their APIs: tor-rtmock tor-log-ratelim tor-rpcbase tor-llcrypto tor-protover tor-bytes tor-hscrypto tor-hspow tor-socksproto tor-checkable tor-cert tor-linkspec tor-cell tor-proto tor-netdoc tor-consdiff tor-netdir tor-congestion tor-persist tor-chanmgr tor-ptmgr tor-guardmgr tor-circmgr tor-dirclient tor-dirmgr tor-keymgr tor-hsclient tor-hsservice tor-hsrproxy arti-client arti-rpcserver arti-config arti-hyper arti-bench arti-testing
* Run maint/fixup-featuresIan Jackson2024-02-051-1/+1
| | | | Discard hunks in examples/
* Mark lower-level hs-service features non-experimentalNick Mathewson2024-01-231-2/+3
|
* Merge branch 'send_incoming_request_failures' into 'main'gabi-2502024-01-173-30/+58
|\ | | | | | | | | | | | | Several clean-ups around failures in incoming stream request handlers. Closes #1190, #1189, and #1188 See merge request tpo/core/arti!1892
| * proto: Use log_ratelim to report problems delivering BEGIN messges.Nick Mathewson2024-01-172-3/+8
| |
| * Give an error on duplicate call to allow_stream_requests.Nick Mathewson2024-01-172-8/+2
| | | | | | | | Closes #1190
| * proto: Close circuit _intentionally_ when Request Sink is dropped.Nick Mathewson2024-01-172-8/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In theory, it might be better to just un-register the IncomingStreamRequestHandler when the Receiver for the stream requests is dropped. However, there are two reasons not to do so: 1. It's tricky. We never actually poll on the corresponding Sink, so there isn't a place where the Reactor would expect to get a prompt notification of closure. We only find out that the Receiver has been dropped when an attempt to send on the Sink returns an `is_disconnected` error. 2. It's unnecessary. In the Tor protocols, once we have decided to accept incoming stream requests on a circuit, we want to continue to do so until one of the parties closes the circuit. I've documented this in several comments, in case whe want to get fancier in the future. Closes #1188.
| * proto: Send END when buffer of IncomingRequests is fullNick Mathewson2024-01-172-13/+14
| | | | | | | | Closes #1189.
* | Remove TODO for #1191Nick Mathewson2024-01-171-3/+0
|/ | | | | | The bug described here was already fixed as #1065 via !1681. Closes #1191.
* proto: Convert a TODO HSS to ticket #1191Nick Mathewson2024-01-101-1/+1
|
* Downgrade and convert TODO HSSs to #1190.Nick Mathewson2024-01-101-2/+2
| | | | | | | | | These are about making allow_incoming_streams give an error if a handler is already installed. I'm calling these non-MUST, since they don't affect the actual API here, and we already have comments telling you not to do that. We can add them later.
* Convert a TODO HSS about excessive BEGINs to #1189.Nick Mathewson2024-01-102-2/+3
|
* proto: Downgrade TODO HSS about HopNum in IncomingStreamRequestCommentNick Mathewson2024-01-102-5/+12
| | | | | | | These comments are about internal representations and future extensions. Also, add a fail-safe check to make sure that hop_num consistency is enforced.
* proto: Downgrade TODO HSS comments about hop lookupNick Mathewson2024-01-101-2/+2
|
* proto: Change some TODO HSS comments to refer to #1188Nick Mathewson2024-01-101-3/+3
|
* Followup patchlevel bumpsNick Mathewson2024-01-091-1/+1
|
* Followup minor version bumps.Nick Mathewson2024-01-091-1/+1
| | | | | | | | These crates had no changes previously, but they depend on crates that had breaking changes themselves. tor-linkspec tor-hspow
* Patchlevel version bumps in preparation for 1.1.12.Nick Mathewson2024-01-091-4/+4
| | | | | | | | | | | | | This crate doesn't have a meaningful public API, so it just gets a patchlevel bump: arti These crates had nonbreaking changes, and get a patchlevel bump: tor-rtcompat fs-mistrust tor-llcrypto tor-cert
* Breaking version bumps in preparation for 1.1.12.Nick Mathewson2024-01-091-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These crates have breaking changes on their own: tor-error tor-netdoc tor-dirmgr tor-keymgr Because of the breaking change in tor-error, and the fact that basically every crate publicly depends on tor-error (by implementing ErrorKind), we need to call this a breaking change on all of the following: tor-config tor-geoip tor-rtmock tor-log-ratelim tor-rpcbase tor-bytes tor-hscrypto tor-socksproto tor-cell tor-proto tor-netdoc tor-netdir tor-persist tor-chanmgr tor-ptmgr tor-guardmgr tor-circmgr tor-dirclient tor-dirmgr tor-keymgr tor-hsclient tor-hsservice tor-hsrproxy arti-client arti-rpcserver arti-config arti-hyper arti-testing
* clippy: consequential rustfmtIan Jackson2024-01-021-8/+2
|
* clippy nightly: For now, locally allow blocks_in_conditionsIan Jackson2024-01-021-0/+1
| | | | | | Filed https://gitlab.torproject.org/tpo/core/arti/-/issues/1176 proposing a final fix.
* clippy: Use infallible callsIan Jackson2024-01-021-4/+2
| | | | Resolves clippy complaints about needless fallible conversions.
* clippy: Replace many calls to .get(0) with .first()Ian Jackson2024-01-022-2/+2
| | | | | FTR I don't think agree with clippy on this question, but then I often don't.
* Rename {Any}RelayCell to {Any}RelayMsgOuterNick Mathewson2023-12-146-38/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-28 10:39:16 +0000