summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | Move intern from tor-netdir to tor-basic-utils and make it pubNick Mathewson2025-12-0310-9/+18
| | |
| * | tor_netdoc::intern: Note a future possible cleanup.Nick Mathewson2025-12-031-0/+2
| | |
| * | protover: Document un-recommended usage of Protocols::new()Nick Mathewson2025-12-031-0/+7
| |/
* | Merge branch 'n_authorities_usize' into 'main'Ian Jackson2025-12-043-7/+6
|\ \ | | | | | | | | | | | | tor-netdoc: Store n_authorities in usize See merge request tpo/core/arti!3522
| * | tor-netdoc: Remove unnecessary castsClara Engler2025-12-042-2/+2
| | |
| * | tor-netdoc: Store n_authorities in usizeClara Engler2025-12-023-5/+4
| | | | | | | | | | | | | | | | | | | | | Previously, this value was stored in a u16. However, because this number is usually always derived from some sort of list type, such as `Vec`, it makes more sense to use usize for this, as it avoid unnecessary casting and error checking.
* | | Merge branch 'fix-rpc-json' into 'main'Nick Mathewson2025-12-041-2/+2
|\ \ \ | | | | | | | | | | | | | | | | Fix the JSON in rpc-book/messages-and-json.md. See merge request tpo/core/arti!3527
| * | | Fix the JSON in rpc-book/messages-and-json.md.Pier Angelo Vendrame2025-12-041-2/+2
| | | | | | | | | | | | | | | | | | | | Added a missing quote and removed a trailing comma to make a JSON snippet from the RPC documentation valid.
* | | | Merge branch 'nd-enc-api-prep' into 'main'Ian Jackson2025-12-043-16/+24
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | tor-netdoc: API etc. changes to support encoding derive See merge request tpo/core/arti!3511
| * | | | tor-netdoc: Provide ItemEncoder::finishIan Jackson2025-12-041-0/+5
| | | | | | | | | | | | | | | | | | | | | | | | | This provides a way to explicitly consume the encoder and finish the item, without use of mem::drop.
| * | | | tor-netdoc: Improve and expose args_raw_stringIan Jackson2025-12-042-3/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The new derive is going to want this. So it would need to be at least `#[doc(hidden)]`. But it makes sense to expose it. But, it had a weird signature. Make its signature like that of `.arg_empty()`. (Note that an ItemEncoder contains just a `&mut NetdocEncoder`.)
| * | | | tor-netdoc: test2: Don't ever have raw String in defaulted argumentsIan Jackson2025-12-041-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These cannot be encoded. So that is logically incoherent. (Perhaps String ought not to be NormalItemArgument, but let's not tackle that now.)
| * | | | 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-0428-31/+33
|\ \ \ \ | | | | | | | | | | | | | | | | | | | | 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-0327-31/+31
| | |_|/ | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This has: * Fixes to hygiene spans from the new modules feature, needed for my WIP netdoc encoder derive. * A substantially richer `${error }` construct.
* | | | Merge branch 'circ-reactor-log-msgs' into 'main'gabi-2502025-12-041-2/+2
|\ \ \ \ | |_|/ / |/| | | | | | | | | | | tor-circmgr: Reduce level of info reactor tracing message See merge request tpo/core/arti!3526
| * | | 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
| | | | |
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 17:33:23 +0000