| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| | |
|
| |\
| |
| |
| |
| |
| |
| | |
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.
|
| |/
|
|
|
|
| |
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.
|
| |\
| |
| |
| |
| |
| |
| | |
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]>
|
| | |
|
| |
|
|
|
| |
Emphasize that circuit expiration functions _decide whether to
expire the circuit_, and don't expire it automatically.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Also, use humantime_serde, rather than a number of seconds, to indicate
configuration time.
|
| |
|
|
|
|
| |
This obeys a few conventions:
* adjective before noun
* config objects end with "config"
|
| | |
|
| |\ |
|
| | | |
|
| | |
| |
| |
| |
| |
| | |
The new CircMgr::build_circuits_preemptively function actually causes
preemptive circuits to be built; it gets called from arti-client, like
the other daemon tasks the CircMgr has.
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
In preparation for making Arti build circuits preemptively, this commit
introduces `TargetCircUsage::Preemptive`, a circuit usage that works
somewhat differently from other ones: it requires at least 2 circuits to
exist that can exit the port it contains in order for an existing
circuit to match against it (path-spec.txt § 2.1.1); if that's not the
case, that usage will require building new circuits (in order that we
build enough to have 2 available).
This required refactoring how circuit reuse worked; now,
`CircList::find_open` uses the new `AbstractSpec::find_supported` trait
method, which we customize to implement the above check in the case of
`Preemptive` circuit usages. To make that work, `OpenEntry` now takes
two type parameters (the spec and circuit types), instead of taking a
builder type parameter and using its associated types. (We also got rid
of type constraints on that struct, yay!)
A WIP implementation of a preemptive circuit predictor that implements
path-spec.txt § 2.1.1 is also included, but this will require additional
effort to wire it up with the `CircMgr` properly.
|
| |/ |
|
| |
|
|
| |
Also use the path_rules name consistently throughout the code.
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
| |
Now that we have two kinds of isolation tokens (those set on a
stream, and those set by the stream's associated TorClient), we
need a more sophisticated kind of isolation.
This fixes the bug introduced with the previous commit, where
per-stream tokens would override per-TorClient tokens.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
It's useful to know now only if we now have the lock, but also if we
just got it for the first time.
|
| |
|
|
|
| |
We can use this in the case where we don't get the lock on the
state file, because another process is running.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
|
|
This will cause some pain for now, but now is really the best time
to do this kind of thing.
|
