| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is a full copy without change (except the keymgr access) so that
function becomes a Reactor function.
Future commit will cleanup the original copy when the crypto reactor
replaces the current task.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This basically copies the code from rotate_keys_task() and puts it in
the run_once().
Cleanup will follow in the next commits to lock step changes.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Signed-off-by: David Goulet <[email protected]>
|
| | |_|/ / /
|/| | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This object wraps the `KeyMgr` and provide getters for all specific
relay key types.
That view is meant to access all keys a relay has. Upcoming restricted
views will wrap that object to offer a limited view that is more domain
specific.
A valid_until cache is kept for all expirable keys so all get() of those
keys always return the same one.
Signed-off-by: David Goulet <[email protected]>
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This is not likely to cause any major problem, so just warning should be
fine.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This currently does not actually export any metrics, but puts the
infrastructure in place to do so.
This adds the `experimental`, `__is_experimental`, etc features to
arti-relay. I presume we want to do that in the long term, but I'm not
100% sure on that.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This will allow these types to be shared by arti and arti-relay.
This does change these types from being behind the experimental-api
flag. I think this is okay, as tor-config is not a stable crate anyways,
but it's worth keeping in mind.
There is also an argument to be made for having two separate types, one
in arti and one in arti-relay, as we do for LoggingConfig. I think that
using a single type has benefits, and we should strive to eventually
merge the LoggingConfigs, for instance, and perhaps other types, but it
doesn't seem critical in either direction at the moment.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Stabilize 'flowctl-cc' and add to 'full'
Closes #2419
See merge request tpo/core/arti!4014
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | | |
|
| |\ \ \ \ \ \
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
ptmgr: pass outbound_proxy to managed PT processes
See merge request tpo/core/arti!4017
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| |\ \ \ \ \ \ \
| |/ / / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-chanmgr: notify waiters when a launch is cancelled
Closes #1716
See merge request tpo/core/arti!3946
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| |\ \ \ \ \ \ \
| |_|/ / / / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
netdir: Fix SRV lifetime calculation for non-standard voting periods
Closes #2522
See merge request tpo/core/arti!3965
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This also adds a test, just make sure creating a `Lifetime` with
voting interval = 0 is actually impossible (and stays that way).
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
It's better to return a `Bug` than to panic if the consensus valid-after
is invalid.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
This is no longer used.
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Remove `use_obsolete_software`.
Closes #1960
See merge request tpo/core/arti!3995
|
| | | |_|_|/ / /
| |/| | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| |\ \ \ \ \ \ \
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
Set socket buffer sizes (`SO_SNDBUF` and `SO_RCVBUF`) for proxy sockets
Closes #2500
See merge request tpo/core/arti!3957
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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`.
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
For now this just sets up the structure. We'll add options for TCP
later.
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
This better matches nearby code.
|
| | | | | | | | | |
|
| | | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | |
| | | | | | | | |
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.
|
| | |_|/ / / / /
|/| | | | | | |
|
| | | | | | | | |
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
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.
|
| | | | | | | | |
|
| | | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
The common suffix isn't needed.
|
| |\ \ \ \ \ \ \
| |_|_|_|/ / /
|/| | | | | |
| | | | | | |
| | | | | | |
| | | | | | |
| | | | | | | |
tor-proto: Don't run vegas algorithm when a clock stall/jump was detected
Closes #2504
See merge request tpo/core/arti!3967
|
