summaryrefslogtreecommitdiff
path: root/crates/tor-guardmgr/src/guard.rs
Commit message (Collapse)AuthorAgeFilesLines
* Run maint/add_warning.Nick Mathewson2024-03-131-0/+1
|
* educe: Use std's default for enums where default variant is unitIan Jackson2024-02-121-7/+4
| | | | | | | | | | | | | Since Rust 1.66, std's default works properly for enums, provided that the default variant is a unit. Review all uses of `#[educe(default)]` on enums and replace them with std where possible, which is most of them. In 1.66 and later, std's `#[derive(Default)]` doesn't infer any generic bounds on the derived impl, where it's an enum - since the unit variant can always be constructed. So this change doesn't add any generic bounds and is not API-visible.
* Run maint/add_warning to add lint block everywhereIan Jackson2023-08-231-0/+1
|
* Stop unconditionally marking bridges as having dir info.Nick Mathewson2023-07-131-4/+0
| | | | | | | | | When we implemented bridges, we added code in 08473872abccf389 to conditionally mark their directory info as present or not present. But the we didn't remove the old code to mark them present unconditionally! Fixes #638.
* Run maint/add_warning to actually apply new lint allowsIan Jackson2023-07-101-0/+1
|
* guardmgr, netdir: fix some needless-mut warningsNick Mathewson2023-05-181-2/+2
| | | | Found by clippy nightly
* tor-guardmgr, tor-proto: minor logging tweakseta2023-05-181-2/+2
| | | | | | | | - We make the tor-guardmgr "We have found that {} is usable" line include the word "guard", otherwise it doesn't appear very useful to a user in safe logging mode, since the guard gets replaced with [scrubbed]. - The "Actually got an end cell..." message is downgraded to DEBUG.
* Allow clippy::unchecked_duration_subtraction in testsNick Mathewson2023-01-271-0/+1
| | | | | This panics on error, and we're fine with a panic on misbehavior in tests.
* test lint blocks: Add many many automaticallyIan Jackson2022-12-121-0/+8
| | | | | This is precisely the result of running the rune in maint/adhoc-add-lint-blocks.
* guardmgr: Conditionalise DisplayRule::RedactedIan Jackson2022-11-291-0/+5
| | | | This is unused in bridgeless configs. Fixes a compiler warning.
* Rustdoc fix: escape []s.Nick Mathewson2022-11-281-1/+1
|
* GuardMgr: Treat Guards as sensitive and Bridges as redacted.Nick Mathewson2022-11-281-5/+40
| | | | | This machinery is a bit inelegant, but it is all confined to be within the GuardMgr crate, so IMO it should be fine for now.
* Display guards in redacted form in guard status messages.Nick Mathewson2022-11-281-3/+3
| | | | | | Closes #627, again. Closes #648.
* GuardMgr: Log when a guard status changes (significantly).Nick Mathewson2022-11-171-1/+17
| | | | | | | | | | | | | | | | We previously had a trace message on _every_ change. That's fine, but we also want to log more important changes where the user can see them. Namely: * If we go from any other status to Reachable, we want to tell the user. (We don't want to spam them if it was already reachable.) * If we go from Untried or Reachable to Unreachable, we want to tell the user. (We don't tell them about changes from Retriable to Unreachable, since that just means that a retry attempt was not successful.) Closes #627.
* GuardMgr: split Reachable::Unknown into Untried and RetriableNick Mathewson2022-11-171-17/+16
| | | | | | | | There are two cases here, and we will want to log them differently. (By removing the "Unknown" variant entirely, we ensure that we didn't miss any code that formerly checked for Unknown.)
* GuardMgr: When possible, return a FirstHop that can be a CircTargetNick Mathewson2022-11-081-1/+0
| | | | | | 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: Fix and improve comments based on review.Nick Mathewson2022-11-021-3/+10
|
* guardmgr: fix rustdoc references.Nick Mathewson2022-11-021-2/+2
|
* guardmgr: Refactor candidate info; add `full_dir_info`Nick Mathewson2022-11-021-4/+27
| | | | | | | Previously we always set `dir_info_missing` to `false` for new guards, since new guards could only be taken from ones that were present in the NetDir. But for bridges, we don't download their info until _after_ we have chosen them as guards.
* guardmgr: Implement Universe for bridges.Nick Mathewson2022-11-021-1/+1
| | | | | Now we can use a group of bridges as the basis for a sample of guards.
* guardmgr: Universe API should look up by ChanTargetNick Mathewson2022-11-021-2/+2
| | | | This will be necessary for bridges.
* guardmgr: take sampled guards from Universe.Nick Mathewson2022-11-021-16/+2
| | | | This is a trickier case, since we have to deal with weights.
* guardmgr: Begin to decouple guards from NetDir.Nick Mathewson2022-11-021-37/+45
| | | | | | | | | | | | | | | In this and the upcoming commits I'll be changing how guards related to `NetDir` and to `Relay`. Previously, a guard could only come from (or be updated from) a `Relay` in a `NetDir`. Soon it will be able to be built from a bridge as well. To do this, I'm defining a `Universe` trait (name negotiable) that represents a set of things that may be guards. I'm going to continue extending its functionality until there are no more methods in guard.rs or sample.rs that take `NetDir`. This commit removes most of the usage of `NetDir` and `Relay` in `guard.rs`.
* guardmgr: Rename microdescriptor_missing to dir_info_missingNick Mathewson2022-11-021-9/+9
|
* guardmgr: Allow guards to be constructed from any ChanTarget.Nick Mathewson2022-11-021-6/+15
|
* guardmgr: Include PtTarget in guards.Nick Mathewson2022-11-021-8/+50
| | | | | Use a vector, since we may (someday) want to allow a Guard to have multiple PtTargets.
* guardmgr: Rename and clarify of non-persistent-state copy fnsNick Mathewson2022-10-271-4/+16
| | | | These will need a bigger overhaul: see #612 and #611.
* Convert guard samples to use ByRelayIds.Nick Mathewson2022-10-251-21/+34
| | | | | | | | | | | | This required a number of changes, which I've tried to document. I've taken a conservative approach to modification, and I'm not using any of the by_*_mut() functions (yet). For cases which potentially modify the whole set, I'm using into_values() and collect() to ensure that it's re-indexed correctly, even though the identities don't change. I introduce some "TODO pt-client" comments here which I will resolve in the next commit(s).
* guardmgr: Refactor the interior of FirstHop.Nick Mathewson2022-10-241-3/+7
| | | | | | | | | | | | | 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: Add bridges sample, encode sample ID in FirstHopId.Nick Mathewson2022-10-211-9/+10
| | | | | | | | | | | | 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.
* Begin revising HasAddr and its relationship to ChanTargetNick Mathewson2022-10-061-0/+2
| | | | | | | | | | | | | | | | | | | 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.
* tor-netdir: Collapse by_id and by_relay_id into a single fn.Nick Mathewson2022-08-101-1/+2
| | | | | | There are some downstream changes required for this to work, but they are all just unit tests that could no longer infer the type of an Ed25519 key.
* Final (?) API revisions for tor-linkspecNick Mathewson2022-08-101-8/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-6/+1
| | | | | 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-11/+20
| | | | | This implementation is (sadly) too copy-heavy or now, because HashSet<RelayId> can't be indexed with RelayIdRef.
* netdir: Add and use a new ids_listed() function.Nick Mathewson2022-08-021-1/+1
|
* Introduce HasRelayIds::same_relay_ids.Nick Mathewson2022-08-021-5/+3
| | | | | This method tells if two HasRelayIds contain exactly the same set of Relay identities, and is generally useful for debugging.
* guardmgr: Replace IdPair with RelayIdsNick Mathewson2022-08-021-9/+9
| | | | 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-2/+8
| | | | | | | | | | | | | | 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.
* tor-netdir: testnet: Make construct_netdir infallible (rustfmt)Ian Jackson2022-06-131-6/+2
| | | | | Run rustfmt. Separate commit to make review of the substantive commit easier.
* tor-netdir: testnet: Make construct_netdir infallibleIan Jackson2022-06-131-2/+0
| | | | | This is a *lot* of unwraps. The function takes no parameters and is used only for testing. It ought to be infallible.
* GuardUsage: restrictions: Use list builderIan Jackson2022-05-041-27/+30
| | | | | | | | | | | | | | Although these do not appear in the config, it does have a builder. It seems sensible to get rid of this ad-hoc list manipulation site, and replace it with our standard list builder API. define_list_builder_helper requires that the builder element type be Deserialize. Currently GuardUsageRestriction is a transparent, public enum, so we aren't really exposing anything. We could introduce GuardUsageRestrictionBuilder now, but since it's not in the config and thereofore only in the public API of the lower crates, we can definitely put that off.
* Initial functions to determine and expose a clock skew estimate.Nick Mathewson2022-04-071-0/+6
| | | | | (This is just a placeholder; I'm going to make the functions smarter in the next commit.)
* GuardMgr: record clock skew information.Nick Mathewson2022-04-071-0/+12
| | | | (It is not yet actually used.)
* GuardMgr: Tests for copy_status_from.Nick Mathewson2022-04-051-0/+6
|
* Rewrite and fix Guard::copy_status_from.Nick Mathewson2022-04-051-11/+28
| | | | | | | | | | | | | | The old version of this function was error-prone, and in fact had errors: it was too easy to forget to add non-persistent fields, and that's exactly what we forgot in a few cases (`microdescriptor_missing`, `circ_history`, and `suspicious_behavior_warned`). The new version of this function consumes both of the incoming Guards, and constructs every field explicitly so that we can't forget to list any. Closes #429.
* GuardMgr: Track directory status and circuit status separately.Nick Mathewson2022-04-051-5/+127
| | | | | | | | | | | | | Previously, we treated successfully building a circuit to a guard as a "success", and any failure, including a directory cache failure, as a failure. With this change, guards now have separate success/failure and retry status for circuit usage and directory usage. This change is needed for guard-as-directory retry to have reasonable behavior. Otherwise, when a guard succeeds at building a circuit, that clears the directory-is-failing status and makes us retry the guards to quickly.
* Fix some Rustdoc links.Nick Mathewson2022-03-301-1/+1
|
* Refactor FirstHopId into type-differentiated formNick Mathewson2022-03-301-35/+29
| | | | | | | | | | | The FirstHopId type now records an enum that stores whether the hop is a guard or a fallback. This change addresses concerns about remembering to check the type or source of an Id before passing it down to the FallbackState or GuardSet. Making this change required an API change, so that dirmgr can report success/failure status without actually knowing whether it's using a fallback or a guard.
* Rename Guard=>FirstHop, GuardId=>FirstHopIdNick Mathewson2022-03-301-13/+21
| | | | | This is preparation for having separate GuardId and FirstHopId types that distinguish which back-end they index.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 21:48:25 +0000