summaryrefslogtreecommitdiff
path: root/crates/tor-proto
Commit message (Collapse)AuthorAgeFilesLines
* Increment patchlevel versions of crates with minor changesNick Mathewson2023-08-011-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These crates are at version 0.x.y, so we don't need to distinguish new-feature changes from other changes: ``` tor-basic-utils fs-mistrust tor-error tor-geoip tor-checkable tor-linkspec tor-netdoc tor-netdir tor-persist tor-ptmgr tor-hsservice ``` This crate has a breaking change, but only when the semver-breaking feature `experimental-api` is enabled: ``` tor-config ``` This crate is at version 1.x.y, but has no new public APIs, and therefore does not need a minor version bump: ``` arti ```
* Update minor versions on crates that have had breaking changesNick Mathewson2023-08-011-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These crates had first-order breaking changes: ``` retry-error tor-keymgr tor-proto tor-hsclient tor-rtmock ``` Additionally, these broke because they re-exposed RetryError: ``` tor-circmgr ``` Additionally, these broke because they may re-expose something from tor-proto: ``` arti-client tor-chanmgr tor-dirclient tor-dirmgr tor-guardmgr ``` Additionally, these broke for other fiddly reasons: `tor-ptmgr` implements traits from tor-chanmgr, which has a breaking change above. `arti-hyper` exposes types from arti-client in its API.
* tor-proto: Rename create_firsthop() to wait_for_create().Gabriela Moldovan2023-07-271-2/+2
|
* tor-proto: Update handle_control docs.Gabriela Moldovan2023-07-261-1/+1
|
* tor-proto: Add functions for handling Shutdown and AddFakeHop messages.Gabriela Moldovan2023-07-261-42/+37
| | | | | This helps reduce code duplication, as `CtrlMsg::Shutdown` and `CtrlMsg::AddFakeHop` are now handled in multiple places.
* tor-proto: Extract first-hop creation to a separate function.Gabriela Moldovan2023-07-261-37/+11
| | | | | | I think it's safe to handle `ChanMsg::Create` separately, because there's nothing for the reactor to do until the first hop of the circuit is created (so blocking on this _should_ be alright).
* tor-proto: Create a function for handling the initial CREATE cell.Gabriela Moldovan2023-07-261-1/+89
| | | | | | This logic from `create_firsthop()` was extracted (copied) from `Reactor::run_once()`. A future commit will update `Reactor::run_once()` to use `create_firsthop()`.
* tor-circmgr: Add two possibly-needed docsrs annotationsIan Jackson2023-07-122-0/+2
| | | | | I don't know if these are needed because the rules are not documented afaict. But it seems like probably they ought to be there?
* tor-proto: Conversation: drop two otiose cfg(feature)Ian Jackson2023-07-122-2/+0
| | | | These fns are in a feature-gated impls on feature-gated structs.
* Merge branch 'clippy-allow' into 'main'Ian Jackson2023-07-1117-0/+17
|\ | | | | | | | | clippy: Allow some of our existing code patterns See merge request tpo/core/arti!1396
| * Run maint/add_warning to actually apply new lint allowsIan Jackson2023-07-1017-0/+17
| |
* | Merge branch 'conversation' into 'main'Alexander Færøy2023-07-105-114/+205
|\ \ | |/ |/| | | | | Overhaul send_control_message See merge request tpo/core/arti!1367
| * tor-proto: run rustfmtIan Jackson2023-06-303-8/+18
| |
| * tor-proto conversations: semverIan Jackson2023-06-301-0/+1
| |
| * tor-proto conversations: Update a TODOIan Jackson2023-06-301-1/+1
| | | | | | | | The feature name is wrong now.
| * tor-proto conversations: Drop a TODOIan Jackson2023-06-301-1/+0
| | | | | | | | I think this name is fine.
| * tor-proto conversation API: Provide ConversationInHandlerIan Jackson2023-06-303-6/+58
| |
| * tor-proto circuit: Plumb async Context throughIan Jackson2023-06-302-3/+8
| | | | | | | | handle_msg is going to want this in a moment.
| * tor-proto conversation API: Soften a warningIan Jackson2023-06-301-1/+4
| | | | | | | | | | If the circuit is just being used by us (which is likely, if we're using this API) then the only reactor we're blocking is our own.
| * tor-proto conversation API: Implement ConversationIan Jackson2023-06-301-89/+98
| | | | | | | | | | Now, after you call start_conversation_last_hop, you can send more messages if you like.
| * tor-proto: Make the handler in SendMsgAndInstallHandler optionalIan Jackson2023-06-302-3/+10
| | | | | | | | | | We're going to want to do almost-the-same thing but without installing a new handler.
| * tor-proto conversation API: Return a ConversationIan Jackson2023-06-302-9/+16
| | | | | | | | | | This is just a placeholder for now, but it'll be a thing you can send more messages with.
| * tor-proto conversation API: Rename to start_conversation_last_hopIan Jackson2023-06-303-10/+10
| | | | | | | | Was send_control_message.
| * tor-proto conversation API: Make starting message optionalIan Jackson2023-06-302-5/+7
| | | | | | | | | | We're going to let people start a conversation and either expect to receive first, or send messages ad-hoc later.
| * tor-proto conversation API: Rename to ConversationFinishedIan Jackson2023-06-301-7/+3
| | | | | | | | | | | | Was UninstallHandler. We are going to talk more about conversations and less about handlers (although, the fact of there being a handler will still be visible).
| * tor-proto circuit: Make reactor::run_once modulae-privateIan Jackson2023-06-301-1/+1
| | | | | | | | Nothing else wants this and having it pub(super) is confusing.
* | Merge branch 'allow_missing_panics' into 'main'Ian Jackson2023-07-073-8/+2
|\ \ | | | | | | | | | | | | | | | | | | add_warning: Tolerate clippy::missing_panics_doc Closes #950 See merge request tpo/core/arti!1380
| * | Remove explicit allows for missing_panics_docs.Nick Mathewson2023-07-062-7/+2
| | | | | | | | | | | | These are no longer needed.
| * | Run add_warning to remove `missing_panics_doc` deny.Nick Mathewson2023-07-061-1/+0
| |/ | | | | | | Closes #950.
* / Avoid matches!(x, None), matches!(x, Ok(_))Nick Mathewson2023-07-061-2/+2
|/ | | | This appeases clippy-nightly.
* Bump patchlevel versions on crates with smaller changesNick Mathewson2023-06-301-8/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Done with the commands below. The following crates have had various changes, and should get a patchlevel bump. Since they are pre-1.0, we do not need to distinguish new APIs from other changes. ``` cargo set-version --bump patch -p arti-client cargo set-version --bump patch -p safelog cargo set-version --bump patch -p tor-bytes cargo set-version --bump patch -p tor-cert cargo set-version --bump patch -p tor-circmgr cargo set-version --bump patch -p tor-config cargo set-version --bump patch -p tor-consdiff cargo set-version --bump patch -p tor-dirclient cargo set-version --bump patch -p tor-dirmgr cargo set-version --bump patch -p tor-error cargo set-version --bump patch -p tor-hsservice cargo set-version --bump patch -p tor-linkspec cargo set-version --bump patch -p tor-llcrypto cargo set-version --bump patch -p tor-netdir cargo set-version --bump patch -p tor-netdoc cargo set-version --bump patch -p tor-proto cargo set-version --bump patch -p tor-rpcbase cargo set-version --bump patch -p tor-socksproto ``` This crate has new features, but no new non-experimental Rust APIs. So even though it is post-1.0, it gets a patchlevel bump. ``` cargo set-version --bump patch -p arti ```
* Bump minor versions on crates with breaking changesNick Mathewson2023-06-301-2/+2
| | | | | | | | | | Done with: ``` cargo set-version --bump minor -p tor-hsclient cargo set-version --bump minor -p arti-rpcserver cargo set-version --bump minor -p tor-hscrypto cargo set-version --bump minor -p tor-cell ```
* Resolve XXXs from fixup-features.Nick Mathewson2023-06-291-3/+2
| | | | | Some of these seem spurious: it looks like fixup-features resolved an issue and then complained about it too. I'll investigate further.
* Run "fixup-features".Nick Mathewson2023-06-291-1/+3
|
* Mark all {hs,onion-serivce}-client features as non-experimental.Nick Mathewson2023-06-291-3/+6
|
* proto: ClientCirc: remove now-obsolete note on Clone-nessNick Mathewson2023-06-281-5/+0
|
* proto: document ClientCirc lifecycle better.Nick Mathewson2023-06-281-0/+29
|
* proto: document channel lifecycle better.Nick Mathewson2023-06-281-5/+24
|
* Merge branch 'ticket_914' into 'main'Nick Mathewson2023-06-282-118/+9
|\ | | | | | | | | | | | | Remove support for receiving unauthenticated SENDMEs. Closes #914 See merge request tpo/core/arti!1283
| * proto: Remove support for receiving unauthenticated SENDMEsNick Mathewson2023-06-262-118/+9
| | | | | | | | | | | | | | We haven't generated these since Tor 0.3.5, which is no longer supported on the network. Closes #914.
* | Back down x25519-dalek to 2.0.0-pre.1 from 2.0.0-rc.2pinkforest2023-06-273-13/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ========================= Notes from nickm: (This differs from pinkforest's original MR: It removes the Cargo.lock changes and the version bump on tor-llcrypto.) Minimal Cargo.lock changes from downgrade. (These are exactly those changes generated by running "build" and "test".) There are several reasons to do this: * It's best to bump all of our dalek dependencies at once to rc.3 or later, rather than the piecemeal approach we've been stuck with so far. * We don't want to do this bump right now, since there are some tricky questions about clamping we need to figure out (see #808), and we need to make sure we get them right, and we're in a distracted this week. * We _do_ need to move away from 2.0.0-rc.2 right now, since it was causing a failure in `cargo install arti`, and then it got yanked. Thanks to pinkforest for helping us out here and explaining all of this! Fixes #926. Commit-edited-by: Nick Mathewson <[email protected]>
* | Upgrade to itertools 0.11.0Nick Mathewson2023-06-261-1/+1
|/ | | | The breaking changes here do not seem to affect us.
* Merge branch 'proto-better-path' into 'main'Nick Mathewson2023-06-223-62/+177
|\ | | | | | | | | | | | | Better API for getting circuit paths Closes #787 See merge request tpo/core/arti!1286
| * proto: Resolve/downgrade some path-related "TODO HS" itemsNick Mathewson2023-06-222-4/+6
| |
| * proto: Implement Redactable and Display for PathEntry.Nick Mathewson2023-06-221-0/+23
| |
| * proto: Add ClientCirc::path_ref(), deprecate path().Nick Mathewson2023-06-221-13/+35
| | | | | | | | | | | | | | | | The new path_ref() method returns an Arc<Path>, which gives a much better API for reasons discussed in the new documentation of path(). (We could just replace path() if we'd prefer, but IMO having path_ref() here isn't so bad.)
| * proto: Make Path and PathEntry at least minimally usefulNick Mathewson2023-06-221-0/+28
| | | | | | | | | | (I'm not 100% sure about having both hops() and iter(). Should I remove one?)
| * proto: Expose an opaque PathEntry.Nick Mathewson2023-06-223-20/+29
| | | | | | | | | | | | The new PathEntry struct wraps the old PathEntry enum, which has been renamed to HopDetail. It's an opaque struct because we want to be able to put new information in the enum as we think best.
| * proto: Make Path publicNick Mathewson2023-06-222-4/+9
| | | | | | | | (You can't get one yet or do much with it.)
| * proto: Remove Mutex from Path.Nick Mathewson2023-06-223-17/+13
| | | | | | | | | | Now Path is a regular struct with no interior mutability, and we use Arc::make_mut() for the case when we need to add a hop.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 21:56:50 +0000