aboutsummaryrefslogtreecommitdiff
path: root/crates/tor-guardmgr/src/lib.rs
Commit message (Collapse)AuthorAgeFilesLines
...
* GuardMgr: Spelling fixes and normalizations.Nick Mathewson2022-11-081-1/+1
|
* GuardMgr: do not use fallbacks when in bridge mode.Nick Mathewson2022-11-081-5/+5
|
* GuardMgr: When possible, return a FirstHop that can be a CircTargetNick Mathewson2022-11-081-3/+28
| | | | | | We do this by checking the FirstHops we're about to return, and when they correspond to bridges, looking up an appropriate BridgeRelay in the current BridgeSet (if we can).
* GuardMgr: Refactor UniverseRef to contains Arcs.Nick Mathewson2022-11-081-14/+18
| | | | | | We already _have_ these Arc<>s whenever we construct a UniverseRef, so there's no real point in using &refs and making these so hard to construct.
* GuardMgr: Remove an outdated "Limitations" comment.Nick Mathewson2022-11-081-10/+0
| | | | Found while grepping for NetDir.
* GuardMgr: do not block netdir if we are using bridgesNick Mathewson2022-11-081-0/+4
| | | | | | | The `GuardMgr` code has functionality to tell the DirMgr "Hey, don't switch to the new NetDir yet: we still need more guard information!" But we never want to do that if we're selecting bridges, since they don't come from the NetDir.
* GuardMgr: Add UniverseType to make code more explicit.Nick Mathewson2022-11-081-7/+28
| | | | | | Instead of duplicating the logic about which guard sample uses which universe, we explicitly ask it, and then use that universe. This will avoid trouble if/when we introduce more samples.
* GuardMgr: Launch a background task to keep the list of bridgeNick Mathewson2022-11-081-1/+10
| | | | descriptors updated as appropriate.
* GuardMgr: Pass correct universe to "Bridges" `GuardSet`.Nick Mathewson2022-11-081-14/+47
| | | | | | This can probably be done in a simpler way, but for the moment I would prefer to try to minimize the amount of code I'm changing here.
* GuardMgr: Store bridge configuration.Nick Mathewson2022-11-081-15/+56
| | | | | | | | | | I'm using an Arc<[]> here though I think that there's a chance that a simple Vec<> would suffice. Since it's an internal type, nothing will break if we change it later. Also, we now switch into and out of the Bridges guard sample as needed. However, that selection is not (yet) built from the list of bridges. That will come soon.
* GuardMgr: Remove duplicate code in set_filterNick Mathewson2022-11-081-13/+2
|
* GuardMgr: Clarify intent with update_active_set.Nick Mathewson2022-11-081-4/+5
| | | | Also fix its behavior when using bridges.
* GuardMgr: Split `update_internal` into two functions.Nick Mathewson2022-11-081-27/+50
| | | | | | The first part changes which guard set is active based on based on the parameters, which always come from a NetDir; the second changes the contents of the active guard set, based on a Universe.
* Refactor external guardmgr APIs: Stop taking NetDir arguments.Nick Mathewson2022-11-081-54/+42
| | | | | | | | | These arguments were used only for legacy (testing) purposes; the tests now use `TestNetDirProvider`. This lets us simplify our internal logic for passing a `NetDir` to our samples, and prepare for having a `BridgeSet` to pass there instead. This is a breaking change to `guardmgr` and `circmgr`.
* Add an accessor for the latest BridgeDescList.Nick Mathewson2022-11-081-0/+12
|
* Implement GuardMgr::install_bridge_desc_providerNick Mathewson2022-11-081-6/+25
|
* guardmgr config: Provide bridge information to new and reconfigureIan Jackson2022-11-031-0/+5
|
* bridges config: Provide uninhabited placeholderIan Jackson2022-11-031-0/+14
| | | | | This will avoid having to make bridge-related trait features in GuardMgr conditional, which would be non-additive.
* guardmgr config: Introduce and require new GuardMgrConfig traitIan Jackson2022-11-031-11/+20
| | | | | It doesn't seem to me like it makes sense to provide the backward compatibility here.
* guardmgr config: Pass fallback list from config by referenceIan Jackson2022-11-031-2/+2
| | | | | This does involve additional cloning. However, soon it will mean that we can pass the whole `TorClientConfig` by reference.
* Run add_warnings.Nick Mathewson2022-11-031-0/+1
|
* guardmgr: Continue porting porting code to use Universe.Nick Mathewson2022-11-021-3/+3
| | | | Two more simple cases that can use Universe instead of Netdir.
* guardmgr: Rename and clarify of non-persistent-state copy fnsNick Mathewson2022-10-271-1/+3
| | | | These will need a bigger overhaul: see #612 and #611.
* guard sample: Change semantics of `contains` to handle ambiguity.Nick Mathewson2022-10-251-4/+15
| | | | | | | | | This is necessary for the (somewhat undesirable) lookup_ids function to return an ID that the dirmgr can actually use to report successes and failures. As noted, lookup_ids will create problems down the road when we implement relays. We should refactor it out before then.
* guardmgr: Refactor the interior of FirstHop.Nick Mathewson2022-10-241-31/+84
| | | | | | | | | | | | | Now it contains either an `OwnedChanTarget` or an `OwnedCircTarget`, which will let `GuardMgr` return bridges that can be used to make circuits. As part of this change, it was necessary to revise some address-modification functions that applied to filters and `OwnedChanTarget`. Now they do the smart thing, and remove only the address that are in the `ChanMethod`. This means that the addresses from HasAddrs are still accurate about which addresses the relay "has".
* guardmgr: Hold FallbackDir in fallback::set::EntryNick Mathewson2022-10-211-2/+5
| | | | This resolves an old TODO, and will simplify our work a little.
* guardmgr: Add bridges sample, encode sample ID in FirstHopId.Nick Mathewson2022-10-211-32/+57
| | | | | | | | | | | | The most important part of this commit is to make sure that each `FirstHopId` includes the `GuardSetSelector` from which the guard was selected. Doing this lets us be certain that when we report that a guard has succeeded or failed, we're reporting it in the right context. Additionally, this commit uses strum to make an iterator over the samples, so that we can make sure that our "for each sample" code is robust against future changes, and we don't miss the bridge sample.
* fix a couple of spelling errors in guardmgrNick Mathewson2022-10-191-1/+1
|
* cargo fmt to remove blank linesIan Jackson2022-10-121-1/+0
| | | | | | | Apparently cargo fmt doesn't like these, which my perl rune didn't delete. This commit is precisely the result of `cargo fmt`.
* Replace all README copies in src/lib.rs with includesIan Jackson2022-10-121-92/+1
| | | | | | | | The feature we want is `#[doc = include_str!("README.md")]`, which is stable since 1.54 and our MSRV is now 1.56. This commit is precisely the result of the following Perl rune: perl -i~ -0777 -pe 's{(^//!(?!.*\@\@).*\n)+}{#![doc = include_str!("../README.md")]\n}m' crates/*/src/lib.rs
* Begin revising HasAddr and its relationship to ChanTargetNick Mathewson2022-10-061-0/+1
| | | | | | | | | | | | | | | | | | | HasAddr used to mean "Here are addresses that I have, at which I can be contacted." But "Where (and how) can I be contacted?" is now a question for HasChannelMethod to answer. (We still need to have "HasAddr", though, so we can answer things like "what country is this relay in" and "are these relays in the same /8?") So this commit introduces: * A new trait for adding an implementation of HasChannelMethod in terms of HasAddr. * A requirement on ChanTarget that it needs to implement HasChannelMethod. There is some temporary breakage here, marked with "TODO pt-client", that I'll fix later in this branch.
* Temporarily suppress a false positive from nightly.Nick Mathewson2022-10-041-0/+5
| | | | | | Nightly rust gives a warning about this "pub use", but the warning is a false positive. Since it doesn't seem to be going away in a hurry, let's suppress it for now.
* Add the necessary APIs for bridge-based circuit construction.Nick Mathewson2022-09-261-0/+10
|
* GuardMgr/DirMgr: Add APIs for bridge descriptor listsNick Mathewson2022-09-261-0/+12
|
* GuardMgr: Add TODOs for bridge support.Nick Mathewson2022-09-261-0/+25
| | | | | | This covers only the most basic notions of working with bridges: that we need a separate set of guards, and that they have to come from the list of known bridges.
* A basic configuration type for a bridge.Nick Mathewson2022-09-261-0/+2
| | | | | | | This type goes in tor-guardmgr, since that's where decisions about circuits' first hops are made. There are a lot of "todo"s here for us to resolve.
* enable doc_auto_cfg feature on every crate when documenting for docs.rstrinity-1686a2022-08-241-0/+1
|
* Make sure all HasRelayIds constaints allow ?Sized.Nick Mathewson2022-08-101-14/+17
|
* Final (?) API revisions for tor-linkspecNick Mathewson2022-08-101-28/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | With this change, each individual identity type becomes optional. The functions that expose them unconditionally are now in a "legacy" trait that only some downstream types are expected to implement. There are new convenience APIs in HasRelayIds: * to return Option<&keytype>, * to see if one identity-set contains another. This commit will break several downstream crates! For the reviewer's convenience, I will put the fixes for those crates into a series of squash! commits on this one. tor-netdir ---------- Revise tor-netdir to accept optional identities. This required some caveats and workarounds about the cases where we have to deal with a key type that the tor-netdir code does not currently recognize at all. If we start to add more identity types in the future, we may well want more internal indices in this code. tor-proto --------- In order to make tor-proto support optional identities, there were fewer changes than I thought. Some "check" functions needed to start looking at "all the ids we want" rather than at "the two known IDs"; they also needed to accommodate that case where we don't have an ID that we demand. This change will also help with bridges, since we want to be able to connect to a bridge without knowing all of its IDs up front. The protocol currently _requires_ the two current ID types in some places. To deal with that, I added a new `MissingId` error. I also removed a couple of unconditional identity accessors for chanmgr; code should use `target().identity(...)` instead. tor-chanmgr ----------- This is an incomplete conversion: it does not at all handle channel targets without Ed25519 identities yet. It still uses those identities to index its internal map from identity to channel; but it gives a new `MissingId` error type if it's given a channel target that doesn't have one. We'll want to revise the map type again down the road when we implement bridges, but I'd rather not step on the channel-padding work in progress right now. tor-guardmgr ------------ This change is mostly a matter of constructing owned identity types more sensibly, rather than unwrapping them directly. There are some places marked with TODOs where we still depend on particular identity types, because of how the directory protocol works. This will need revisiting when we add bridge support here. tor-circmgr ----------- These changes are just relatively simple API changes in the tests.
* Introduce a RelayIdSet and use it in place of HashSet<RelayId>.Nick Mathewson2022-08-101-5/+3
| | | | | This makes lookups a little more efficient. I do with that HashSet just supported this use-case, but for now this seems our best option.
* Teach guard restrictions about RelayId.Nick Mathewson2022-08-101-3/+6
| | | | | This implementation is (sadly) too copy-heavy or now, because HashSet<RelayId> can't be indexed with RelayIdRef.
* guardmgr: Change APIs that used to take IDs.Nick Mathewson2022-08-021-14/+9
| | | | These are the other inspiration for #428.
* guardmgr: Replace IdPair with RelayIdsNick Mathewson2022-08-021-2/+2
| | | | I believe that this was the original motivation behind #428.
* tor-linkspec: Refactor out traits to represent a relay's ID set.Nick Mathewson2022-08-021-5/+6
| | | | | | | | | | | | | | We want the set of identities supported by a relay to be extensible in the future with minimal fuss; we'd also like to make working with these ID sets more convenient. To handle that, this commit adds a new trait for "Something that has the same IDs as a relay" and a new object for "an owned representation of a relay's IDs." This commit introduces a similar trait for "Something with a list of SocketAddr, like a relay has." There's no owned equivelent for that, since Vec<SocketAddr> is already a thing. Closes #428.
* GuardMgr: Update to use new NetDirProvider API.Nick Mathewson2022-07-261-3/+3
|
* Run maint/add_warning crates/*/src/{lib,main}.rsIan Jackson2022-06-231-0/+3
| | | | Update all lint blocks
* Rename guardset-selection function.Nick Mathewson2022-06-171-2/+7
| | | | Also, improve its documentation.
* Rename pick_guard, pick_guard_ext.Nick Mathewson2022-06-171-1/+1
| | | | | | Now the primary exposed function is `pick_guard` again. This commit is just function renaming.
* Refactor and document issues with modify_hop.Nick Mathewson2022-06-171-12/+2
| | | | | | | | | | | | At the site of modify_hop, we now have a comment explaining the internal-error issue. To make the internal error less likely, we lower the modify_hop call in lib.rs into GuardSet, where it can make sure it's looking at the same filter as was used to select the guard. The function name "pick_guard_ext" is not permanent; I'm going to rename it in the next commit.
* API-fix for extend_sample_as_needed.Nick Mathewson2022-06-171-10/+3
| | | | | | | | | Previously, the API said "you need to call this in a loop till it returns false". We did that in one place, but not another. With the introduction of filters, forgetting to loop here becomes a bug: so instead, change the behavior of extend_sample_as_needed so it handles looping itself.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-27 02:25:39 +0000