mirror of https://gitlab.torproject.org/tpo/core/arti http://git.dilluti0n.com/mirrors/arti.git/atom?h=arti-v1.1.1 2022-11-29T19:31:48Z 2022-11-29T19:31:48Z Nick Mathewson nickm@torproject.org 2022-11-29T19:31:48Z urn:sha1:7ef9dde99cfd70db86eaf3a3b86953d24941dfcf chanmgr: resolve several remaining "TODO pt-client" issues See merge request tpo/core/arti!897 2022-11-29T18:41:35Z Nick Mathewson nickm@torproject.org 2022-11-29T16:21:41Z urn:sha1:8cc09c27289718a82bffd7353f9db3442fdf0e96 2022-11-29T15:56:59Z Nick Mathewson nickm@torproject.org 2022-11-29T15:56:59Z urn:sha1:69744ef8f34f80c6099f25545b20b77c43471d45 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-11-22T18:09:06Z eta tor@eta.st 2022-11-22T18:01:32Z urn:sha1:2f75702cec4d58ce64ddca5a0ea28a6ab8cd853c It doesn't make much sense to have the pluggable transport manager be a registry, so replace its interface with a more narrowly defined, less generic version. Other changes: - instead of returning a &-reference, it returns an owned Arc, which should make the ptmgr easier to implement while allowing efficient reuse - provision for error handling is added, but will probably be revised in a future commit pending discussion - tor-ptmgr code that would generate warnings as a result of this change is temporarily removed This is a split out version of arti!886, intended so work on arti#659 can proceed. 2022-10-20T12:11:00Z Nick Mathewson nickm@torproject.org 2022-10-18T14:00:57Z urn:sha1:f39157f8c33518f21a6355c736c0dadd26aa096c This is mostly a matter of encoding parameters in the format used for socks authentication. 2022-10-18T19:39:33Z Nick Mathewson nickm@torproject.org 2022-10-18T19:39:33Z urn:sha1:5786637b4fb520373c1713bb3bd2d65d41e8ef08 2022-10-18T15:49:21Z Nick Mathewson nickm@torproject.org 2022-10-18T15:30:51Z urn:sha1:06132d9f350e1469edf8d28c6c8b64b96900ace0 This can happen in weird corner cases, so it's probably best to report it rather than having an "internal error." 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. }