summaryrefslogtreecommitdiff
path: root/crates/tor-guardmgr/src/guard.rs
Commit message (Collapse)AuthorAgeFilesLines
* tor-guardmgr: Port to web_time_compat.Nick Mathewson2026-03-261-19/+20
|
* tor-guardmgr: fix some duration string formattingSteven Engler2026-03-241-1/+1
| | | | | | Old text would say something like: > Retrying in FormattedDuration(29.999861026s).
* Fix name of clippy lint to unchecked_time_subtraction (2)Ian Jackson2025-11-061-1/+1
| | | | Run maint/add_warning
* tor-guardmgr: Ignore cognitive_complexity lint.Wesley Aptekar-Cassels2025-10-161-0/+1
| | | | | While this is fairly nested, it's short, and most of the complexity is just in the logging code.
* tor-guardmgr: Use humantime for some logging.Wesley Aptekar-Cassels2025-10-161-1/+1
|
* tor-guardmgr: Add retry time to guard failure warning.Wesley Aptekar-Cassels2025-10-161-7/+14
| | | | | The "Next retry time unknown" message can't be hit right now, but could be if the code changes in the future.
* tor-linkspec: Change HasAddrs::addrs to return an Iterator (fmt)Ian Jackson2025-10-061-1/+4
|
* tor-linkspec: Change HasAddrs::addrs to return an IteratorIan Jackson2025-10-061-7/+8
| | | | | | | | This will let us model the actual structure of routerstatus entries in netdocs more closely. They don't have the addresses in a single list. When this code was written this would have been much more awkward, but now we have RPITIT.
* Switch Cargo.toml files to edition 2024.Nick Mathewson2025-08-071-2/+2
| | | | | | | | | | | | | | First, run ``` git grep -l "^edition =" | xargs perl -i -pe 's/^edition *=.*/edition = "2024"/;' ``` Second, manually verify that all Cargo.toml files have changed, and nothing else has changed. Third, run cargo fmt again.
* Typo fixes (automatic and hand-verified)Nick Mathewson2025-07-091-1/+1
| | | | Made with https://crates.io/crates/typos-cli
* Run cargo fmtNick Mathewson2025-03-181-11/+3
|
* squash! Upgrade rand dependency to 0.9.Nick Mathewson2025-03-181-3/+3
| | | | - `rand::thread_rng()` has been deprecated and renamed to `rand::rng()`
* tor-netdir: Allow access to the `ConsensusBuilder` when building test netdirs.Gabriela Moldovan2024-09-091-2/+2
| | | | | This allows us to set SRVs for example (needed because by default, the test `NetDir` is built from a consensus that doesn't contain any SRVs).
* 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.
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 21:48:19 +0000