mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.0 2022-11-30T18:58:37Z 2022-11-30T18:58:37Z Nick Mathewson nickm@torproject.org 2022-11-30T18:58:37Z urn:sha1:903571353b8959383963ebf50ec8527fdd19a95b Renaming a couple of items for arti 1.1.0 Closes #623 See merge request tpo/core/arti!916 2022-11-30T18:22:54Z Nick Mathewson nickm@torproject.org 2022-11-30T18:22:54Z urn:sha1:6bd0f92c15b1080c19a7ab196b9998166a7254d1 2022-11-30T18:05:46Z Nick Mathewson nickm@torproject.org 2022-11-30T18:05:46Z urn:sha1:acc2de7b31625c5c9664eca3d699686ae4601c8f 2022-11-30T15:49:34Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-11-30T15:07:52Z urn:sha1:199a6e0754581c15ca26096989e35aa021412e97 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. 2022-11-28T18:52:21Z eta tor@eta.st 2022-11-28T15:32:56Z urn:sha1:a3c9fc5b1aa9f1072448fdea336f561b71ce1176 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). 2022-11-23T18:28:38Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-11-23T15:05:58Z urn:sha1:e635383dfb6662ec8f26a2c2549f30ba78b7f514 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. 2022-11-23T18:28:38Z Ian Jackson ijackson@chiark.greenend.org.uk 2022-11-23T15:20:01Z urn:sha1:32357b3de7cfbb393877b24ff9ad402e89a7e014 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. 2022-10-18T15:49:21Z Nick Mathewson nickm@torproject.org 2022-10-15T12:14:43Z urn:sha1:c802d39b8012b06301693362575beb5a440a4e73 Thanks to our previous changes, we no longer need this type, or the methods that access it. 2022-10-18T15:49:21Z Nick Mathewson nickm@torproject.org 2022-10-14T21:54:24Z urn:sha1:c78bacce86c8a47e9bec011fe4d4d72c9e8924ed 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. } 2022-10-13T14:32:02Z Nick Mathewson nickm@torproject.org 2022-10-13T14:32:02Z urn:sha1:31528202c581cbfc03da50f26d7801ee04e5425c