| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |\ \
| | |
| | |
| | |
| | |
| | |
| | | |
CI: Add client auth integration test.
Closes #954
See merge request tpo/core/arti!1399
|
| | | | |
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
"Fix" CI complaints about "Conversation"
See merge request tpo/core/arti!1402
|
| | | |
| | |
| | |
| | |
| | | |
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?
|
| | | |
| | |
| | |
| | | |
These fns are in a feature-gated impls on feature-gated structs.
|
| |/ / |
|
| |\ \
| | |
| | |
| | |
| | | |
Expose channel builder in order to create channels more efficiently in external code
See merge request tpo/core/arti!1374
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | | |
|
| | | |
| | |
| | |
| | | |
These errors aren't ignored anymore.
|
| |\ \ \
| | | |
| | | |
| | | |
| | | | |
Explain the code for the #952 fix.
See merge request tpo/core/arti!1391
|
| | | | |
| | | |
| | | |
| | | |
| | | | |
Let's explain what Trinity did in its fix for #952, so that we know
why this code is here the next time we find it.
|
| |\ \ \ \
| | | | |
| | | | |
| | | | |
| | | | | |
clippy: Allow some of our existing code patterns
See merge request tpo/core/arti!1396
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
This launders the closure so that clippy's
clippy::redundant_closure_call can't see it.
We can't have a local #[allow] because it would be on an expression,
which isn't allowed on stable.
This avoids having to use more clumsy idioms at call sites.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
This fixes a needless_vec lint on nightly.
|
| | | | | | |
|
| | | | | | |
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
Fixes #920
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
There are a number of places where we generate random Durations
in a range which starts at zero.
These call sites currently (i) have to write out Duration::ZERO
or equivalent, and (ii) would have to use gen_range_checked and expect
the result, even though it can be statically proven to be OK.
To make this slightly smoother, provide `GenRangeInfallible` and
`gen_range_infallible`.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Ideally we would be allowed to use vanilla gen_range() here, but there
doesn't seem to be a way to allow a specific clippy-forbidden method
using #[allow] and we probably don't want to make a blanket allow.
|
| | | | | | |
|
| | | | | |
| | | | |
| | | | |
| | | | | |
In each of these, it is locally obvious that the range is nonempty.
|
| | | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
delay_bounds's implementation ensures the postcondition, so the
potential p[anic in next_delay_msec cannot happen.
|
| | | | | |
| | | | |
| | | | |
| | | | | |
We will use this in many places instead of gen_range.
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
keymgr: Use Box<dyn EncodableKey> instead of Box<dyn Any>.
Closes #937
See merge request tpo/core/arti!1398
|
| | | | | | | |
|
| | |/ / / /
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | |
| | | | | |
Prompted by https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/1337#note_2917701
This will make it harder to accidentally return the wrong value from
`Keystore::get` (the returned value is now at least guaranteed to
implement `EncodableKey`).
Closes #937
|
| |\ \ \ \ \
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Overhaul send_control_message
See merge request tpo/core/arti!1367
|
| | | | | | | |
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
The feature name is wrong now.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
I think this name is fine.
|
| | | | | | | |
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
handle_msg is going to want this in a moment.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
Now, after you call start_conversation_last_hop, you can send more
messages if you like.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to want to do almost-the-same thing but without installing
a new handler.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
This is just a placeholder for now, but it'll be a thing you can send
more messages with.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | | |
Was send_control_message.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
We're going to let people start a conversation and either expect to
receive first, or send messages ad-hoc later.
|
| | | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | |
| | | | | | |
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).
|