aboutsummaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
...
| * | | | | tor-proto: move 'flowctl-cc' from 'experimental' to 'full'Steven Engler2026-05-221-2/+2
| | | | | |
* | | | | | Merge branch '3777_rebased' into 'main'Nick Mathewson2026-05-265-5/+30
|\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | ptmgr: pass outbound_proxy to managed PT processes See merge request tpo/core/arti!4017
| * | | | | | ptmgr: Defer proxy protocol string conversionNihal2026-05-264-8/+12
| | | | | | |
| * | | | | | ptmgr: pass outbound_proxy to managed PT processesNihal2026-05-264-4/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously the [channel] outbound_proxy setting was applied to Arti's own direct connections but was not forwarded to managed PT processes. https://spec.torproject.org/pt-spec/configuration-environment.html
* | | | | | | Merge branch 'fix-channel-build-task-disappeared' into 'main'Nick Mathewson2026-05-264-119/+188
|\ \ \ \ \ \ \ | |/ / / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tor-chanmgr: notify waiters when a launch is cancelled Closes #1716 See merge request tpo/core/arti!3946
| * | | | | | tor-chanmgr: Notify waiters when a launch is cancelledBoris Nagaev2026-05-044-119/+188
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a future that owns a pending channel launch is dropped after publishing the pending entry, other waiters can see the oneshot sender disappear and report "channel build task disappeared" as an internal bug. Fix this by tying pending-entry cleanup and waiter notification together. Once we take responsibility for a pending launch, every exit path now removes or upgrades the pending entry and notifies waiters with the observed result. Cancellation reports RequestCancelled, while post-build failures keep their original error instead of turning into the internal bug or retrying the launch owner. Add regression tests that cover both successive dropped launch-owner futures and a failure while installing a newly built channel, so waiters see the expected error in each case.
* | | | | | | Merge branch 'srv-fixes' into 'main'gabi-2502026-05-262-34/+147
|\ \ \ \ \ \ \ | |_|/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | netdir: Fix SRV lifetime calculation for non-standard voting periods Closes #2522 See merge request tpo/core/arti!3965
| * | | | | | hsservice: Set the current random value for the custom netdirGabriela Moldovan2026-05-211-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This test was supposed to set both the current and the previous SRV in the test netdir, but was actually only setting the previous one. With the new SRV fixes from ee07c441909b41d5fbbfbffae310e954a69db478, all the hsservice tests using this netdir were panicking on an `.unwrap()`, because the SRV for the "previous" TP could not be found, which is actually what you'd expect to happen, given that the netdir was built with only one SRV. The reason the tests weren't failing before is, funnily enough, because of the bug in SRV calculation that is fixed in ee07c441909b41d5fbbfbffae310e954a69db478: In `tor-netdir`, the `extract_srvs()` function (correctly) only returned a single SRV from the consensus (the "previous one", set with `bld.shared_rand_prev()` in the test), but the `find_params_for_time()` was wrongly matching up that same SRV with multiple time periods. This happened because the old implementation was computing the "previous SRV" validity interval as: * ts_begin = `[start_of_day_containing(consensus_ts) - ONE_DAY` * ts_end = `ts_begin + srv_interval` And because the test SRV interval is 288h(!), and the test TP length is only 24h, the validity period of the previous SRV (incorrectly) covered two TPs (both the previous and the current). So as a result, the test was "successfully" getting back the same SRV for both the previous and the current TP. The bug was introduced in the commit that originally added the hsservice tests: 279842526591918e25ca97e6392f211a50192396
| * | | | | | netdir: Add a debug_assert to ensure the voting interval is non-zeroGabriela Moldovan2026-05-211-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This also adds a test, just make sure creating a `Lifetime` with voting interval = 0 is actually impossible (and stays that way).
| * | | | | | netdir: Add a test for start_of_sr_protocol_run()Gabriela Moldovan2026-05-211-0/+77
| | | | | | |
| * | | | | | netdir: Make start_of_sr_round() fallibleGabriela Moldovan2026-05-211-10/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | It's better to return a `Bug` than to panic if the consensus valid-after is invalid.
| * | | | | | netdir: Remove a no longer needed constantGabriela Moldovan2026-05-211-3/+0
| | | | | | |
| * | | | | | netdir: Remove start_of_day_containing()Gabriela Moldovan2026-05-211-29/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This is no longer used.
| * | | | | | netdir: Fix SRV lifetime calculation for non-standard voting periodsGabriela Moldovan2026-05-211-3/+25
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes Arti's SRV lifetime calculation for the case where the voting interval != 1h, and the consensus doesn't have explicit timestamps for the SRVs. Credit goes to dgoulet for this fix! See also [this thread], and #2458 for the broader context. Closes #2522 [this thread]: https://gitlab.torproject.org/tpo/core/arti/-/work_items/2458#note_3401343
* | | | | | | Merge branch 'no-version-override' into 'main'wesleyac2026-05-217-131/+11
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Remove `use_obsolete_software`. Closes #1960 See merge request tpo/core/arti!3995
| * | | | | | | Remove `use_obsolete_software`.Nick Mathewson2026-05-147-135/+15
| | |_|_|/ / / | |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Discussion on #1960 suggests that this option is not a good idea: it encourages developers to work around deliberate signals that the software they're shipping won't work on the network. Closes #1960.
* | | | | | | Merge branch 'ci-backtrace' into 'main'wesleyac2026-05-211-0/+2
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | CI: turn on RUST_BACKTRACE for all jobs See merge request tpo/core/arti!3999
| * | | | | | | CI: turn on RUST_BACKTRACE for all jobsIan Jackson2026-05-181-0/+2
| |/ / / / / / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | I just had a situation where the backtrace might have been helpful, arti#2538, https://gitlab.torproject.org/Diziet/arti/-/jobs/1539809. I was surprised to find we don't seem to turn this on and never have!
* | | | | | | Merge branch 'socket-buf-size' into 'main'opara2026-05-2128-63/+435
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Set socket buffer sizes (`SO_SNDBUF` and `SO_RCVBUF`) for proxy sockets Closes #2500 See merge request tpo/core/arti!3957
| * | | | | | | tor-rtcompat: improve comments related to socket optionsSteven Engler2026-05-212-3/+32
| | | | | | | |
| * | | | | | | tor-proto: add note about proxy socket buf sizesSteven Engler2026-05-071-0/+1
| | | | | | | |
| * | | | | | | arti: add 'proxy.socket_{send,recv}_buf_size' config optionsSteven Engler2026-05-074-23/+58
| | | | | | | |
| * | | | | | | arti: use 128 KB socket buffers for proxy socketsSteven Engler2026-05-071-2/+18
| | | | | | | |
| * | | | | | | tor-rtcompat: add options to set the socket buf sizesSteven Engler2026-05-072-2/+25
| | | | | | | |
| * | | | | | | tor-rtcompat+misc: add `NetStreamProvider::ListenOptions`Steven Engler2026-05-0721-58/+224
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds the trait type `ListenOptions` to `NetStreamProvider` and adds this `ListenOptions` as an argument to `NetStreamProvider::listen()`. You probably want to look at the changes in tor-rtcompat first, then the rest of this commit is updating the various places we use `NetStreamProvider`.
| * | | | | | | tor-rtcompat: add structs to hold listen() optionsSteven Engler2026-05-074-0/+102
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For now this just sets up the structure. We'll add options for TCP later.
* | | | | | | | Merge branch 'stream-refactor' into 'main'opara2026-05-2112-231/+185
|\ \ \ \ \ \ \ \ | |_|_|/ / / / / |/| | | | | | | | | | | | | | | | | | | | | | | tor-proto: Move more stream queue/channel initialization to the reactor See merge request tpo/core/arti!4009
| * | | | | | | tor-proto: destructure the `ReactorStreamComponents`Steven Engler2026-05-211-5/+12
| | | | | | | |
| * | | | | | | tor-proto: have `StreamReqInfo` store a `ReactorStreamComponents`Steven Engler2026-05-216-49/+41
| | | | | | | |
| * | | | | | | tor-proto: add a TODO item for XON/XOFF flow controlSteven Engler2026-05-211-0/+3
| | | | | | | |
| * | | | | | | tor-proto: move memquota stream account arg to last positionSteven Engler2026-05-215-11/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This better matches nearby code.
| * | | | | | | tor-proto: clean up `CIRCUIT_BUFFER_SIZE`Steven Engler2026-05-214-12/+2
| | | | | | | |
| * | | | | | | tor-proto: move more stream queue init to reactorSteven Engler2026-05-217-149/+86
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously when initializing a stream, we constructed most of the stream-related queues outside of the reactor and passed the relevant halves of the queues (senders or receivers) into the reactor. A downside of the above approach is that the reactor may be better informed about what queues to construct, and how to construct them. For example the reactor knows what type of flow control that the hop is using, so it knows whether we need queues for passing rate limits and drain rates for XON/XOFF flow control. This commit moves the construction of these queues into the reactor and passes the relevant halves out of the reactor. In the future we can make better decisions about which queues are needed depending on the flow control method used instead of always constructing them (see arti#2068). Reviewing with `--color-moved` might be helpful as a few lines have been moved.
| * | | | | | | tor-proto: add `ReactorStreamComponents` to bundle return valsSteven Engler2026-05-207-29/+54
|/ / / / / / /
* | | | | | | Merge branch 'cc-buf-size' into 'main'opara2026-05-2113-123/+145
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tor-proto: Determine stream inbound message queue's capacity at runtime Closes #2536 See merge request tpo/core/arti!3981
| * | | | | | | tor-proto: small comment improvementsSteven Engler2026-05-202-1/+3
| | | | | | | |
| * | | | | | | tor-proto: remove unneeded type aliasSteven Engler2026-05-201-5/+2
| | | | | | | |
| * | | | | | | tor-proto: always use a bounded mpsc queue for streamsSteven Engler2026-05-203-39/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Whether a stream queue should be bounded or unbounded is a decision that needs to be made at runtime depending on the type of flow control used, not at build-time. Window-based flow control should be bounded and XON/XOFF flow control should be unbounded. If we wanted to support both bounded and unbounded queues, it would take a bunch of boilerplate code to wrap the senders and receivers in enums. Instead we make the queue always bounded, but use a large bound for XON/XOFF flow control.
| * | | | | | | tor-proto: add `FlowCtrlHooks::inbound_queue_max_len()`Steven Engler2026-05-203-1/+35
| | | | | | | |
| * | | | | | | tor-proto: move stream incoming queue init to reactorSteven Engler2026-05-207-69/+82
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The stream queue length (for messages incoming from the Tor network) depends on the type of flow control we're using for the hop. Currently we construct the stream queue outside of the circuit reactor, but we don't have the flow control information here. Instead of constructing the stream queue outside of the reactor and passing the sender into the reactor, we construct the stream queue inside of the reactor and pass the receiver out of the reactor.
| * | | | | | | tor-proto: small cleanup of `CircHopOutbound::build_flow_ctrl()`Steven Engler2026-05-201-11/+4
| | | | | | | |
| * | | | | | | tor-proto: rename `{,Half}StreamFlowCtrlInner` variantsSteven Engler2026-05-201-10/+10
|/ / / / / / / | | | | | | | | | | | | | | | | | | | | | The common suffix isn't needed.
* | | | | | | Merge branch 'vegas-stall' into 'main'David Goulet2026-05-204-14/+36
|\ \ \ \ \ \ \ | |_|_|_|/ / / |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tor-proto: Don't run vegas algorithm when a clock stall/jump was detected Closes #2504 See merge request tpo/core/arti!3967
| * | | | | | tor-proto: vegas: return early if clock stall was detectedSteven Engler2026-05-073-10/+23
| | | | | | |
| * | | | | | tor-proto: rtt: return clock stall/jump status from `update()`Steven Engler2026-05-071-4/+13
| | | | | | |
* | | | | | | Merge branch 'keymgr-raw-ids' into 'main'opara2026-05-1910-132/+88
|\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | keymgr: more docs for the `RawEntryId` APIs, and some dead code removal See merge request tpo/core/arti!3997
| * | | | | | | keymgr: Add a TODO about possibly removing RawEntryId::EphemeralGabriela Moldovan2026-05-181-0/+11
| | | | | | | |
| * | | | | | | keymgr: Rephrase the remove_unchecked docs for clarityGabriela Moldovan2026-05-181-5/+5
| | | | | | | |
| * | | | | | | keymgr: Clarify that not all keystores support stringly-typed entry IDsGabriela Moldovan2026-05-181-0/+12
| | | | | | | |
| * | | | | | | keymgr: Remove a couple unused From<> implsGabriela Moldovan2026-05-183-20/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | These are unused, and I don't think they're needed by our API users either, since `KeystoreEntryResult` is just a type alias for `Result`.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 14:21:36 +0000