aboutsummaryrefslogtreecommitdiff
path: root/crates
Commit message (Collapse)AuthorAgeFilesLines
...
* | | | tor-netdoc: Better error from empty argument (fmt)Ian Jackson2025-12-041-1/+4
| | | |
* | | | tor-netdoc: Better error from empty argumentIan Jackson2025-12-041-1/+1
| | | | | | | | | | | | | | | | | | | | talking about the "keyword argument syntax" makes it sound a bit like its' the *keyword* that is wrong.
* | | | tor-netdoc: Throw rather than squirreling error from NormalItemArgumentIan Jackson2025-12-041-3/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | NormalItemArgument is for types where we use the Display as the netdoc argument formatter. But what if gives the empty string? Previously we would allow `add_arg` to handle the error. That would record it in the NetdocEncoder. That's kind of OK, but it will prevent the caller from aborting early (and from elaborating the error).
* | | | tor-netdoc: Explain some downsides to use of ItemEncoder::argIan Jackson2025-12-041-0/+3
| | | |
* | | | Merge branch 'deftly-1.6.0' into 'main'Ian Jackson2025-12-0427-27/+29
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | Update to derive-deftly 1.6.0 See merge request tpo/core/arti!3525
| * | | | tor-netdoc: Suppress a clippy warning more thoroughlyIan Jackson2025-12-041-1/+2
| | | | |
| * | | | Pin our derive-deftly version to ~1.6.0 everywhereIan Jackson2025-12-036-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We are supposed to pin whenever we enable the `beta` cargo feature, see https://docs.rs/derive-deftly/latest/derive_deftly/doc_changelog/index.html#beta-features Empirically, we somehow failed to do that in tor-circmgr. In practice not pinning makes little difference since cargo wants to pick the same version everywhere, but we should be correct. But it is more maintainable to pin everywhere.
| * | | | tor-netdoc: Suppress a clippy warningIan Jackson2025-12-031-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This code sometimes expands to `let item = item;`. That's OK. In derive-deftly 1.5.x the two `item` wrongly had different hygiene span so the warning didn't trigger.
| * | | | Update to derive-deftly 1.6.0Ian Jackson2025-12-0326-27/+27
| | |/ / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has: * Fixes to hygiene spans from the new modules feature, needed for my WIP netdoc encoder derive. * A substantially richer `${error }` construct.
* | | | tor-circmgr: small comment fixSteven Engler2025-12-031-1/+1
| | | |
* | | | tor-circmgr: reduce level of info reactor tracing msgSteven Engler2025-12-031-1/+1
| | | | | | | | | | | | | | | | | | | | Since "info" is the default level, we don't want to log by default each time a circuit reactor is created.
* | | | Merge branch 'torclient-keymgr-accessor' into 'main'wesleyac2025-12-032-12/+16
|\ \ \ \ | |/ / / |/| | | | | | | | | | | Add `KeyMgr` accessor to `TorClient` See merge request tpo/core/arti!3442
| * | | arti: keys: use `TorClient::keymgr` instead of `InertTorClient::keymgr` in ↵hjrgrn2025-11-051-12/+10
| | | | | | | | | | | | | | | | | | | | | | | | `run_check_integrity` This change simplifies the signature of `run_check_integrity`.
| * | | arti-client: Add `TorClient:keymgr` getter functionhjrgrn2025-11-051-0/+6
| | | |
* | | | Merge branch 'bug-context' into 'main'gabi-2502025-12-032-0/+34
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | tor-error: Provide new `bug_context` method on Bug and Result<_, Bug> See merge request tpo/core/arti!3512
| * | | | tor-error: Provide new `bug_context` method on Bug and Result<_, Bug>Ian Jackson2025-12-012-0/+34
| | | | | | | | | | | | | | | | | | | | | | | | | This allows call sites which have a `Bug` to add additional context, beyond just the stack trace.
* | | | | Merge branch 'relay-streams2' into 'main'David Goulet2025-12-0218-696/+1658
|\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | proto: Start handling incoming streams in the relay reactor See merge request tpo/core/arti!3487
| * | | | | proto: Remove incorrect padding logicGabriela Moldovan2025-12-021-18/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This was all wrong, as mentioned in https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/3487#note_3296033
| * | | | | proto: Add TODO about our TRUNCATE plansGabriela Moldovan2025-12-021-0/+5
| | | | | |
| * | | | | proto: Move EXTEND handling to catch-all errorGabriela Moldovan2025-12-022-9/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since EXTEND is not used anymore, it's fine to handle it in our catch-all branch for unrecognized/unsupported cells.
| * | | | | proto: Explain why we have the backward sink readiness checkGabriela Moldovan2025-12-021-4/+26
| | | | | |
| * | | | | proto: Resolve some clippy warnings, remove allowsGabriela Moldovan2025-11-242-6/+3
| | | | | |
| * | | | | proto: Reword a nonsensical TODOGabriela Moldovan2025-11-241-3/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This TODO was copied over from the client reactor, but it doesn't make any sense here (we don't yet handle control messages in the backward reactor).
| * | | | | proto: Update relay reactor documentationGabriela Moldovan2025-11-241-8/+79
| | | | | |
| * | | | | proto: Fix a number of newly broken doc linksGabriela Moldovan2025-11-245-5/+7
| | | | | |
| * | | | | proto: Appropriately gate STREAM_READER_BUFFER to satisfy clippyGabriela Moldovan2025-11-241-1/+4
| | | | | |
| * | | | | proto: Adjust docs to refer to the new location of StreamReceiverGabriela Moldovan2025-11-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | While we still re-export StreamReceiver from the client module, I want to avoid importing it from there in the implementation-agnostic modules, just to make it clearer we're not using client-specific types.
| * | | | | proto: Deduplicate msg_streamid()Gabriela Moldovan2025-11-243-40/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Initially I wanted to turn `msg_streamid()` into a method on `UnparsedRelayMsg`, but I ultimately decided against it, because it feels like it doesn't belong there (even though intuitively, I would've expected it to handle the mismatch between stream ID and cell command internally). This is because all the `UnparsedRelayMsg` methods return `tor_bytes::Result`, and do not actually do any validation beyond some length checks on the various fields.
| * | | | | proto: Remove crate-level STREAM_READER_BUFFER reexportGabriela Moldovan2025-11-242-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | All this indirection is making me dizzy.
| * | | | | proto: Move a couple of stream-related constants to stream mod (fmt)Gabriela Moldovan2025-11-244-7/+5
| | | | | |
| * | | | | proto: Move a couple of stream-related constants to stream modGabriela Moldovan2025-11-247-25/+20
| | | | | |
| * | | | | proto: Start handling incoming stream requestsGabriela Moldovan2025-11-243-28/+666
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The relay reactor is now able to handle incoming stream requests (i.e. cells that open streams). It currently only supports DATA stream requests (BEGIN); support for other stream types (BEGIN_DIR, RESOLVE) will be added later. `Reactor::new()` now returns the futures::Stream of Tor streams, alongside the `Reactor` and `RelayCirc` handle. Whoever calls `Reactor::new()` is responsible for passing the stream of streams over to the task that is meant to handle it ("handle" in this case means either rejecting the stream with a given `END` cell, or accepting it and forwarding the connection between it and the corresponding application stream). IMPORTANT: the above is a bit half-baked! Next on my TODO list is is to iron out the details of how/where this will actually be handled. I am also a bit unsure about the API here: I think it might've been nicer to give the user the ability to obtain this `futures::Stream` from `RelayCirc`, which is, after all, a handle to the reactor? Also on my short-term TODO list is to figure out how conflux will affect this API and usage. And there is another wrinkle here: for incoming DATA stream requests, the handler will need to produce a resulting `DataStream`, which is not yet fully implementation-agnostic (it wraps a `ClientDataStreamCtrl`). This too will be handled in a separate MR.
| * | | | | proto: Pass all the padding-related objects to the relay reactorsGabriela Moldovan2025-11-243-2/+24
| | | | | | | | | | | | | | | | | | | | | | | | These will need to be handled soon
| * | | | | proto: Make send_msg_to_client() take an AnyRelayMsgOuterGabriela Moldovan2025-11-241-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed because we will soon have another callsite for it, which will need to pass `AnyRelayMsgOuter`.
| * | | | | proto: Add a Tunnel::Relay variant for StreamTargetGabriela Moldovan2025-11-243-10/+114
| | | | | |
| * | | | | proto: Add WIP constructor for relay sync viewGabriela Moldovan2025-11-241-0/+6
| | | | | |
| * | | | | proto: Move StreamComponents to top-level stream modGabriela Moldovan2025-11-243-22/+24
| | | | | |
| * | | | | proto: Move raw under top-level stream modGabriela Moldovan2025-11-243-7/+3
| | | | | |
| * | | | | proto: Move StreamTarget to stream moduleGabriela Moldovan2025-11-244-163/+177
| | | | | |
| * | | | | proto: Make StreamTarget take a generic TunnelGabriela Moldovan2025-11-241-42/+90
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is needed because we want to reuse `StreamTarget` and `DataStream` on the relay side too, but to do that, we need to abstract away the tunnel/circuit type (prior to this MR, `StreamTarget` was was client-specific, as it used to wrap a client tunnel). Note that `StreamTarget` needs a handle to the client/relay circuit reactor because it needs to be able to shut down the circuit if a protocol error occurs (cells carrying stream data are parsed late, *outside* of the reactor, so if e.g. a cell fails to parse, the `DataReaderImpl` needs to be able to shut it down), and because it needs to be able to inform the reactor of flow control-related events (such as drain rate update).
| * | | | | proto: Make the hop in StreamTarget optionalGabriela Moldovan2025-11-241-6/+6
| | | | | | | | | | | | | | | | | | | | | | | | For relays, the hop of the StreamTarget will be set to `None`.
| * | | | | proto: Add an IncomingStreamConfig to pass to the reactorGabriela Moldovan2025-11-241-2/+12
| | | | | |
| * | | | | proto: Rework relay reactor error handlingGabriela Moldovan2025-11-241-8/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I've made `run()` more similar to its client circuit reactor counterpart (I think the error reporting will be better, and if we ever need to make the reactor public, it will be easier this way because now `run()` doesn't expose the crate-private `ReactorError` type).
| * | | | | proto: Rename RelayReactor to ReactorGabriela Moldovan2025-11-243-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is already namespaced under the `relay` module so the `Relay` prefix is redundant.
| * | | | | proto: Give RelayCirc a DynTimeProviderGabriela Moldovan2025-11-242-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | This will be needed soon.
| * | | | | proto: Move StreamReqInfo to stream moduleGabriela Moldovan2025-11-243-55/+60
| | | | | |
| * | | | | proto: Make the hop in StreamReqInfo optionalGabriela Moldovan2025-11-243-6/+3
| | | | | | | | | | | | | | | | | | | | | | | | We are about to use `StreamReqInfo` for exit streams too.
| * | | | | proto: Move IncomingStream* types to shared moduleGabriela Moldovan2025-11-243-305/+300
| | | | | |
| * | | | | proto: Make the forward -> backward reactor chan boundedGabriela Moldovan2025-11-243-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This MPSC channel now has zero buffering, because if the backward reactor can't send the cell, the forward reactor must immediately stop reading from its inputs (note that the backward reactor's Tor channel towards the client *does* have a buffering layer).
| * | | | | proto: Let cell_rx carry more than just stream dataGabriela Moldovan2025-11-242-21/+46
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are other types of messages (like circuit-level SENDMEs) that need to be handled in the backward reactor too.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 23:01:10 +0000