[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]

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

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

Comment (by dcf):

 Replying to [comment:10 cohosh]:
 > Okay, these changes look good to me. Some things I noticed while going
 through to code again:
 >
 > - there's something up with the go.sum file you generated that's causing
 security errors for me. Specifically the hash for `github.com/tjfoc/gmsm`
 seemed wrong. I fixed this by removing go.sum and then regenerating it.
 Can you take a look at your end and see if you're having the same issues?

 Good catch. This was essentially an upstream packaging error which I've
 reported at https://github.com/tjfoc/gmsm/issues/56. The v1.3.0 you can
 download from proxy.golang.org and the v1.3.0 you can download from
 github.com are not the same. I'm guessing that someone once did a `go get`
 with the v1.3.0 tag pointing at the wrong place, and now it's impossible
 to removed that version from proxy.golang.org and sum.golang.org. I use
 `GOPROXY=direct` and `GOSUMDB=off` because I don't like the `go` command
 constantly phoning home, which is hy my download had come from github.com
 and I got a different checksum.

 The only reason gmsm@v1.3.0 was in go.mod at all was a single import in in
 kcp-go that was missing the `/v5` suffix, causing it to grab the newest
 version of all its dependencies instead of the versions in go.mod. I
 [https://github.com/xtaci/kcp-go/pull/170 fixed] that `/v5` error a few
 weeks ago and now it only depends on gmsm@v1.0.1, which doesn't have a
 proxy/non-proxy checksum problem.

 > - for the changes in
 [https://gitweb.torproject.org/user/dcf/snowflake.git/commit/?h
 =turbotunnel-merge&id=43f540e23d49af6ea75389ddc8808fdb1d482d5e this
 commit], it looks like we can still end up with a blocking goroutine
 waiting to read from a KCP stream once the SOCKS connection closes.

 When one of the two goroutines finishes, control goes back to `Handler`,
 which closes both connections, which should cause the other goroutine to
 finish.

 Another way to do this would be to move the Conn closing into the
 `copyLoop` function, where each goroutine, when it finishes, closes the
 Conn that makes the other finish.

 >  In fact, since the KCP stream is kept alive, will this stay open
 indefinitely (or until Tor Browser restarts/closes)?

 `webRTC` in this case is an smux stream, contained within the KCP stream.
 The KCP stream lasts forever but smux streams come and go. The smux stream
 gets closed in a caller
 [https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h
 =turbotunnel-merge&id=085461013ae616ce540643d4e5c6b6378d7474ca#n91 here].

 > - this is a nitpick, but the comments and variable names in `Handler`
 and `copyLoop` still assume this is a WebRTC session and not a KCP stream
 [https://gitweb.torproject.org/user/dcf/snowflake.git/tree/client/lib/snowflake.go?h
 =turbotunnel-merge&id=619802d12707baf5aee7091a7f1c02c3dbcaa30c#n166 here].

 Thanks, I changed the comment and variable name in `copyLoop`. I think the
 references to WebRTC in `Handler` are appropriate because they refer to
 the connection before any KCP or smux has been layered on it.

 I made the changes in
 [https://gitweb.torproject.org/user/dcf/snowflake.git/log/?h=turbotunnel-
 merge-2&id=2022496d3b6fc76b7725135758c37d7d49546d3d turbotunnel-merge-2]
 and merged in [https://gitweb.torproject.org/pluggable-
 transports/snowflake.git/log/?id=2022496d3b6fc76b7725135758c37d7d49546d3d
 2022496d3b6fc76b7725135758c37d7d49546d3d].

--
Ticket URL: <https://trac.torproject.org/projects/tor/ticket/33745#comment:11>
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