| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| ... | |
| | |
|
| |
|
|
|
|
|
| |
Provide an enum variant to contain the SpawnError and a From impl.
We use `#[from]` here because it doesn't really make sense to attach
any context, as it's not likely to be very relevant.
|
| |
|
|
| |
This will be used for error handling, and perhaps other things.
|
| |
|
|
|
|
|
|
| |
The type annotation may not be necessary for inference, but as a
comment it risks becoming false. So it should be uncommented, or
deleted.
Error types round here are not entirely trivial so uncomment it.
|
| |\
| |
| |
| |
| | |
Fix typos
See merge request tpo/core/arti!285
|
| | | |
|
| | | |
|
| |/
|
|
|
|
| |
Prompted by clippy::needless_question_mark. Sometimes Ok(r?) is
needed to do automatic error conversion. I assume the lint checks for
that. Anyway, in these cases it's not needed.
|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
Refactor our Runtime implementations to allow replacement parts
Closes #255
See merge request tpo/core/arti!251
|
| | |
| |
| |
| |
| | |
This will make it easier to implement them using some other TLS
provider as well, without having to duplicate all of our code.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The docs even say this is about stream.
As @nickm writes in
https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/252#note_2771289
we generally call end-to-end connections that are tunneled over Tor
"Streams" to distinguish them from everything else in the Tor
protocols that could possibly be called a "Connection".
That seems to apply here too.
|
| | |
| |
| |
| |
| |
| | |
This is totally not just an exercise to get combined test coverage
for tor-circmgr over 90% because I needed something to do that
wouldn't distract anybody else. :)
|
| | |
| |
| |
| |
| |
| | |
Since it implements a "<=" type relationship, it should be called
"at_least_as_permissive_as()." Since it's a crate-private function,
the long name isn't too bad.
|
| |/
|
|
| |
This was added by mistake.
|
| |\
| |
| |
| |
| |
| |
| | |
Fix ticket 178: Don't use a NetDir until we have microdescriptors for all of our primary guards.
Closes #178
See merge request tpo/core/arti!220
|
| | |
| |
| |
| |
| |
| |
| | |
We need this information to know if it's okay to migrate to a new
NetDir, or if we need to download more information first.
Part of #178.
|
| |\ \ |
|
| | | | |
|
| | | |
| | |
| | |
| | |
| | |
| | | |
See the new commentary text on `ClientCirc` for the rationale.
Signed-off-by: Ian Jackson <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
We are going to get rid of the Arc. Happily there is an id which is
always constructed uniquely and preserved by clone.
(auto-deref lets us make the function take &Self instead of &Arc)
Signed-off-by: Ian Jackson <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This removes a lot of open-coded Arc::ptr_eq() calls
Signed-off-by: Ian Jackson <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | | |
This will make the code work when it's not an Arc any more.
Signed-off-by: Ian Jackson <[email protected]>
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | | |
We are going to get rid of a lot of Arc, so we need the underlying
thing to be Clone.
Signed-off-by: Ian Jackson <[email protected]>
|
| |\ \ \
| |/ /
|/| |
| | |
| | | |
tor-circmgr: Remove a type annotation in a method call
See merge request tpo/core/arti!225
|
| | | |
| | |
| | |
| | |
| | |
| | |
| | |
| | | |
This is a method, so the resolution is automatic. It's not clear to
me why this was written out this way, given that extend_ntor is right
above.
Signed-off-by: Ian Jackson <[email protected]>
|
| |/ / |
|
| |\|
| |
| |
| | |
# Conflicts:
# crates/tor-circmgr/src/build.rs
|
| | |\ |
|
| | | | |
|
| | |/ |
|
| |/ |
|
| |
|
|
|
|
|
| |
This closes arti#256. It makes our behavior match Tor's more closely,
though it has a simpler implementation than Tor. I think that the extra
complexity in Tor's logic is because we used to record timeouts in
the histogram as well as in the success/failure log.
|
| |\
| |
| |
| |
| | |
preemptive.rs: Use Instant::checked_add instead of raw subtraction
See merge request tpo/core/arti!206
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
The implementations of `Add` / `Sub` (et al.) on `std::time::Instant`
can panic if the underlying OS structure can't represent the result
(like arti#266). Use Instant::checked_add and print a warning instead,
to prevent panicking.
Also, we now add instead of subtracting; I suspect it's reasonable that
you might not be able to go backward past the first `Instant` created on
some platforms, but going *forward* should probably work?
|
| | |
| |
| |
| |
| |
| | |
IIUC, these anticipatd a need to store min_exit_circs_per_port in
CircMgr. But the current design, where it goes into preemptive.rs and
thence to usage, seems to work fine.
|
| | | |
|
| | | |
|
| | |
| |
| |
| |
| | |
Emphasize that circuit expiration functions _decide whether to
expire the circuit_, and don't expire it automatically.
|
| |/ |
|
| |\
| |
| |
| |
| | |
Make most arti-client fields reconfigurable.
See merge request tpo/core/arti!181
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
Most notably, make min_exit_circs_for_port actually get used.
Also add a couple of comments.
|
| | |
| |
| |
| |
| |
| | |
This required re-centralizing the configuration object for preemptive
circuits, since previously the settings from it were a bit spread out
over the crate.
|
| | | |
|
| | |
| |
| |
| |
| | |
(These weren't in the codebase when I started the first version of
this branch.)
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
And now the complexity begins: when the user changes the path_rules,
they not only want new circuits to obey those rules: they want
_all new requests_ to be put onto circuits that obey those rules.
That means that when the path rules become more restrictive, we need
to retire all the circuits, and make sure that currently pending
circuits aren't used for any requests.
If it's any comfort, doing this was even more complicated in C tor. ;)
|
| | |
| |
| |
| |
| |
| |
| | |
This patch doesn't actually make anything reconfigurable, but it
does create an API that will tell you "you can't change the value of
that!" If the API looks reasonable, I can start making it possible
to change the values of individual items.
|
| | | |
|
| | | |
|
