On Wed, May 24, 2023 at 9:10 PM David Fifield <da...@bamsoftware.com> wrote: > > Linus Nordberg and I will have a paper at FOCI this summer on the > special way we run tor on the Snowflake bridges to permit better > scaling. It discusses the two workarounds from the post below, namely a > shim for predictable ExtORPort auth, and disabling onion key rotation. > This setup has been in place on Snowflake bridges since January 2022. > About 2.5% of Tor users (all users, not just bridge users) access Tor > using Snowflake, so it's not a niche use case even if it's just us. > > One of the reviewers asked if there was a chance changes might be made > in tor that make our workarounds unnecessary. Is there anything to say > to this question? Might tor get a feature to control ExtORPort > authentication or onion key rotation, or is something that's planned to > stay as it is in favor of Arti? (Arti will probably remove the need for > the load-balanced multi-tor configuration, which will also remove the > need to disable onion key rotation, though better control over ExtORPort > auth could still be useful for running server PTs that are not child > processes of arti.)
I can't speak definitively about the plans for the C tor implementation. My understanding is that they are hoping to keep new features there to a minimum, so I don't know if this would be something they can do. In Arti, we're a lot more open to that kind of stuff. We're not planning to start a relay implementation till next year at the earliest, but please remind us when we start working on ExtOrPort and related things and we can try to figure out a design that works. _______________________________________________ tor-dev mailing list tor-dev@lists.torproject.org https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-dev
