Re: [tor-bugs] #33745 [Circumvention/Snowflake]: Merge a turbotunnel branch

["Tor Bug Tracker & Wiki" <blackhole@xxxxxxxxxxxxxx>]

#33745: Merge a turbotunnel branch
-------------------------------------+--------------------------
 Reporter:  dcf                      |          Owner:  dcf
     Type:  task                     |         Status:  assigned
 Priority:  Medium                   |      Milestone:
Component:  Circumvention/Snowflake  |        Version:
 Severity:  Normal                   |     Resolution:
 Keywords:  turbotunnel              |  Actual Points:
Parent ID:  #19001                   |         Points:
 Reviewer:                           |        Sponsor:
-------------------------------------+--------------------------

Comment (by cohosh):

 Replying to [comment:2 dcf]:
 > Replying to [ticket:33745 dcf]:
 > > * Decide between the
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
 kcp KCP] and [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h
 =turbotunnel-quic QUIC branch].
 >
 > On this point, I advocate for the kcp-go branch. I think that quic-go
 will be the cause of a lot of maintenance difficulties. There's nothing
 really wrong with QUIC the protocol (apart from it still being a changing
 standard); the problem is the instability of the quic-go package.
 >  * quic-go doesn't have a stable API, and the API
 [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-quic&id=42c07f2c140e4c6f1f752329a67fdf15cd6bd8c5 has broken]
 in the time I've been using it.
 >  * quic-go is tightly coupled to a specific version of Go and its
 standard library, because it uses internal data structures of the
 crypto/tls package. If you compile quic-go with the wrong version of Go,
 you get an error not at compile time but at runtime. The version of quic-
 go currently being used requires Go 1.13, which means it cannot be built
 in Tor Browser until Tor Browser upgrades its own version of Go, which is
 currently stalled pending changes in rbm (#32027). It cuts the other way
 as well: any future upgrade of Go will require a simultaneous upgrade of
 quic-go and work to fix any API breakage.
 >  * Upgrading quic-go past where it is now pinned will add a lot of
 weighty dependencies (comment:15:ticket:33336).
 >  * The quic-go repository is volatile. Not
 [[comment:1:ticket:33401|once]] but [https://github.com/lucas-clemente
 /quic-go/issues/2172 twice] I encountered significant bugs whose fix was
 only a few days or weeks old, not yet in any numbered release.
 >  * Different versions of quic-go do not necessarily interoperate.
 Specifically, I know that the version of quic-go currently packaged in Tor
 Browser (as a dependency of pion-webrtc), which is less than one year old,
 does not interoperate with current versions of quic-go, because the old
 version does not send ALPN in its TLS handshake, and newer versions
 require it.
 >
 > Could I be wrong in my assessment? Of course. kcp-go is not perfect
 either--in particular I'm thinking about patching it to remove what of its
 dependencies we don't use. If quic-go were the only option, I would say go
 ahead with it, and live with the maintenance costs. But my considered
 opinion is that it is more risky to deploy a system based on quic-go than
 one based on kcp-go and smux.
 As you mentioned earlier, the intent of the quic branch was to take
 advantage of the fact that pion/webrtc already requires pion/quic to
 build. pion/quic requires quic-go commit [https://github.com/lucas-
 clemente/quic-go/commit/907071221cf97f75398d9cf8b1174e94f56e8f96 907071]
 at the moment, which is an earlier version that we're using here, and
 before the large dependencies are added. It's possible (maybe even likely)
 they will eventually move to a more recent version of quic-go so we'll
 have to include it anyway to keep up to date on the webrtc library and get
 things like security updates.

 Honestly this is where the go ecosystem is causing a lot of pain. We don't
 even use pion/quic. We only need it to build the project. Digging into
 this a bit more, it looks like the code in
 [https://github.com/pion/webrtc/blob/master/quictransport.go
 quictransport.go] is only ever used in examples, and is an optional
 feature of [https://ortc.org/ ORTC], which we do not use.Looking at the
 code, a patch to remove this dependency would be quite simple. We'd pretty
 much need to just remove a few files.

 I'm inclined to agree with going with KCP. The only concerns I can find
 that we had with it are that it added more new depencies (looks like about
 16) and most are again for features we don't use.

 There seems to be many good opportunities for dependency pruning across
 the board. I wish there was a way to make go libraries that allowed for
 the automatic disabling of unused features to avoid this kind of bloat.

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33745#comment:4>
Tor Bug Tracker & Wiki <https://trac.torproject.org/>
The Tor Project: anonymity online

_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs