summaryrefslogtreecommitdiff
path: root/crates/tor-chanmgr/src/builder.rs
Commit message (Collapse)AuthorAgeFilesLines
* Run maint/add_warning.Nick Mathewson2024-03-131-0/+1
|
* Run maint/add_warning to add lint block everywhereIan Jackson2023-08-231-0/+1
|
* Run maint/add_warning to actually apply new lint allowsIan Jackson2023-07-101-0/+1
|
* 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.
* Merge branch 'renaming' into 'main'Nick Mathewson2022-11-301-5/+5
|\ | | | | | | | | | | | | Renaming a couple of items for arti 1.1.0 Closes #623 See merge request tpo/core/arti!916
| * Rename TransportHelper => TransportImplHelper.Nick Mathewson2022-11-301-5/+5
| |
* | Downgrade a "TODO pt-client" commentNick Mathewson2022-11-301-1/+3
|/
* Separate BridgeAddr and PtTargetAddrIan Jackson2022-11-301-2/+6
| | | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/issues/668#note_2858220 This commit is difficult to split up. The innards of BridgeAddr and PtTargetAddr are still a bit entangled.
* tor-chanmgr: Introduce the BootstrapReporter API, publicize ChanBuildereta2022-11-281-22/+15
| | | | | | | | | | | | | | | | | | | | | | | | This commit makes the `ChanBuilder` type in `tor-chanmgr` usable by consumers outside of that crate, like the doc comment for `ChannelFactory` says you need to be able to do in order to turn your `TransportHelper` into something useful. As part of doing this, the `event_sender` its constructor takes needed to be dealt with, since it was a crate-internal type that came from inside the `ChanMgr`. Enter `BootstrapReporter`: an opaque wrapper around that sender, now provided as an additional argument to `ChannelFactory::connect_via_transport`. You can now construct a `ChanBuilder` outside this crate, and it'll still be able to report its bootstrap status by unwrapping this new type that's threaded through from the `ChanMgr`. (This was a fair deal of manually threading the type through all the layers in this crate!) Note that you cannot implement bootstrap updating using something that isn't `ChanBuilder` yet due to the type being entirely opaque (but, of course, we can figure out exactly what API the reporter should have later, and add that capability in).
* tor-chanmgr: Invent [Box]ChanSensitive for two error payloadsIan Jackson2022-11-231-1/+1
| | | | | | | | | | | This 1. Makes the errors smaller (in the case of Io's PtTargetAddr; ChannelBuild's addresses are already indirected in a Vec). 2. Redacts (currently, scrubs) the PtTargetAddr and SocketAddr when safe logging is enabled These are the remaining error variants in tor-chanmgr that contain information that should become sensitive as part of bridge support.
* tor-chanmgr: Replace OwnedChanTarget with LoggedChanTarget in errorsIan Jackson2022-11-231-4/+4
| | | | | | | | | This 1. Makes the errors smaller 2. Redacts (currently, scrubs) the chantarget when safe logging is enabled This commit doesn't treat other should-be-sensitive inforemation in errors just yet. That will come in a moment.
* chanmgr: Remove "Ident" from AbstractChannelNick Mathewson2022-10-181-12/+5
| | | | | Thanks to our previous changes, we no longer need this type, or the methods that access it.
* chanmgr: replace the HashMap<> with a ByRelayIds.Nick Mathewson2022-10-181-2/+2
| | | | | | | | | | | | | | | | | | This is necessary so that we can look up channels (open and pending) by all of the Ids that we know about them. The operations needed here are pretty complex: to get them right, I've replaced most of the accessors on the inner `ChannelMap` with a function that holds the lock while another `FnOnce` is called. This still gets us the invariant that we can't accidentally await while holding the lock on the `ChannelMap`. I've removed the tests for the accessors that are no longer there. There are some subtleties here. Now that we have more than one kind of Id, it's possible to have a partial match. I've tried to explain all these cases in the comments. }
* chanmgr: Edit comments, fix docsNick Mathewson2022-10-131-3/+11
|
* ChanMgr: Reorganize factory, builder, transport code.Nick Mathewson2022-10-131-221/+8
| | | | There is no actual code change here: just movement.
* Flatten TimeoutChannelFactory into ChannelBuilder.Nick Mathewson2022-10-131-46/+29
|
* Allow multiple ChannelBuilders to share a ChanMgrEventSender.Nick Mathewson2022-10-131-4/+8
|
* chanmgr: Move Timeout functionality into a decorator object.Nick Mathewson2022-10-131-10/+46
|
* Have ChannelBuilder use TransportHelper.Nick Mathewson2022-10-131-22/+85
| | | | | | This lets us build channels using different TransportHelpers, including the (new) default TransportHelper, which just uses the old connect_to_one() code.
* Rename mgr::ChannelFactory to mgr::AbstractChannelFactoryNick Mathewson2022-10-121-2/+2
| | | | | | | | | This is an internal type (distinct from factory::ChannelFactory) that we use to make the code in `tor_chanmgr::mgr` agnostic about what a channel actually is, and how it is actually launched. Therefore, I'm renaming it and giving better documentation in a couple of places, to prevent confusion.
* Change multiplicity of ChannelMethod and addressesNick Mathewson2022-10-111-12/+8
| | | | | | | Now each `ChanTarget` has at most one `ChannelMethod`, and only `Direct` `ChannelMethods` can have multiple addresses. Closes #600.
* Allow two useless pattern matches that are going to be not uselessIan Jackson2022-10-111-0/+1
|
* Move two users of HasAddrs to HasChannelMethodsNick Mathewson2022-10-061-2/+11
| | | | All the other users of HasAddrs are correct.
* tor-linkspec: Remove the old OwnedFoo::new() functionsNick Mathewson2022-10-061-1/+8
| | | | These are now builders.
* tor-proto: Preserve the ChannelMethod, not the SocketAddrNick Mathewson2022-10-061-1/+1
|
* tor-chanmgr: don't log addresses so much.Nick Mathewson2022-08-251-2/+3
| | | | | We now log connection attempts at debug!, and mark relay target addresses as sensitive.
* Rename ChannelsParams types to ChannelPaddingInstructions (fmt)Ian Jackson2022-08-171-1/+4
| | | | Run rustfmt; no other changes.
* Rename ChannelsParams types to ChannelPaddingInstructionsIan Jackson2022-08-171-2/+2
| | | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826167 This makes some lines too long; I will run rustfmt in a separate commit for clarity.
* Channel: Make mutable() and engage_padding_activities infallibleIan Jackson2022-08-171-3/+2
| | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826151 This gets rid of quite some Bug error paths.
* Move ChannelUsage from tor_proto to tor_chanmgrIan Jackson2022-08-171-3/+2
| | | | | | | | | | | Replace Channel::note_usage with Channel::engage_padding_activities, which unconditionally causes the channel to (start to) do netflow padding things. The condition now lives in chanmgr. Addresses https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/657#note_2826094
* Provide ChannelUsage and plumb it all the way downIan Jackson2022-08-161-0/+5
| | | | | | | | | | | | | Channel padding depends on what the channel is being used for. We therefore need to let the channel code know this information. The implementation of the per-channel padding control logic will be in the new note_usage function, which for now is simply a stub. A future commit will introduce a `PaddingControlState` which lives in the channel frontend; consult the doc comment for that type to see why the plumbing through the channel manager terminates in the channel frontend.
* channel reparameterize: Change error typeIan Jackson2022-08-161-3/+2
| | | | This is going to be able to fail in other ways too, sadly.
* Final (?) API revisions for tor-linkspecNick Mathewson2022-08-101-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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.
* tor-linkspec: Refactor out traits to represent a relay's ID set.Nick Mathewson2022-08-021-1/+1
| | | | | | | | | | | | | | 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.
* ChanMgr: errors: attribute errors to correct address.Nick Mathewson2022-07-061-3/+7
| | | | | | Even when keys are relevant, we still don't want to attribute errors to a set of addresses when we have a single address that we're connected with.
* ChanMgr: Add more contextual info to error types.Nick Mathewson2022-07-061-8/+16
| | | | | | Now each type has a peer. In some cases this peer is just an address, whereas in others (where key is relevant or address isn't yet narrowed down) it's a full OwnedChanTarget.
* channel padding: Rename ChannelsParams from ChannelsConfigIan Jackson2022-06-211-3/+3
| | | | | | | As per https://gitlab.torproject.org/tpo/core/arti/-/merge_requests/586#note_2814276 Change names and comments and docs everywhere.
* channel padding: Plumb settings from chanmgrIan Jackson2022-06-211-0/+5
|
* Plumb a SleepProvider into the channel reactorIan Jackson2022-06-081-1/+4
| | | | | The channel reactor is going to want to be able to sleep so that it can do padding, so it needs a SleepProvider.
* chanmgr: expose whether we are failing because of expired certs.Nick Mathewson2022-04-121-0/+4
|
* chanmgr: bubble ClockSkew up through the Error object.Nick Mathewson2022-04-071-3/+15
| | | | | | | | Fortunately, we don't need a separate type here: authenticated clock skew can only come attached to a `tor_proto::Error`. We also remove skew from `tor_proto::Error::HandshakeCertsExpired`, since it would now be redundant.
* chanmgr: add a test for AbstractChannel::duration_unusedNick Mathewson2022-04-021-1/+9
|
* chanmgr: add tests for connect_one.Nick Mathewson2022-04-021-2/+84
|
* tor-proto: add a backend to detect reported clock skew.Nick Mathewson2022-03-231-1/+4
| | | | | | | | | | | | | | | | NETINFO cells, which are sent in every handshake, may contain timestamps. This patch adds an accessor for the timestamp in the Netinfo messages, and teaches the tor-proto code how to compute the minimum clock skew in the code. The computation isn't terribly precise, but it doesn't need to be: Tor should work fine if your clock is accurate to within a few hours. This patch also notes a Y2038 problem in the protocol: see torspec#80. Part of #405.
* Implement a basic form of RFC 8305 ("happy eyeballs") for channelseta2022-03-071-21/+75
| | | | | | | | | | | | This makes Arti usable in IPv6-only environments (arti#92) by letting us attempt multiple connections to a given relay using all of its addresses instead of just using the first (probably IPv4) one, using the strategy from RFC 8305 ยง 5. This isn't a complete implementation of Happy Eyeballs; ideally, we'd sort the address list before doing concurrent connections. However, it works (and has been tested inside an IPv6-only container inside eta's network :p)
* tor-chanmgr: use Bug types.Nick Mathewson2022-02-161-5/+5
|
* Merge branch 'error-improvements' into 'main'eta2022-02-081-3/+5
|\ | | | | | | | | Hopefully uncontroversial improvements to new Error code See merge request tpo/core/arti!291
| * Make SpawnError wrappers contain a 'spawning' stringNick Mathewson2022-02-041-3/+5
| | | | | | | | | | (By our convention, these errors should say what we were trying to spawn when the error occurred.)
* | Expire channels that have been unused for too longYuan Lyu2022-02-041-0/+4
|/
generated by cgit v1.2.3 (git 2.46.0) at 2026-08-26 21:44:31 +0000