[tbb-bugs] #22831 [Applications/Tor Browser]: Merge Snowflake for mac

Tor Bug Tracker & Wiki blackhole at torproject.org
Thu Jul 13 19:47:32 UTC 2017


#22831: Merge Snowflake for mac
--------------------------------------------+------------------------------
 Reporter:  dcf                             |          Owner:  tbb-team
     Type:  task                            |         Status:
                                            |  needs_revision
 Priority:  Medium                          |      Milestone:
Component:  Applications/Tor Browser        |        Version:
 Severity:  Normal                          |     Resolution:
 Keywords:  snowflake TorBrowserTeam201707  |  Actual Points:
Parent ID:                                  |         Points:
 Reviewer:                                  |        Sponsor:
--------------------------------------------+------------------------------

Comment (by dcf):

 Replying to [comment:3 gk]:
 > Looks good. The `needs_revision` is mainly for the following nits:
 >
 > s/clang 0.3.8/clang 3.8.0/
 >
 > s/The linux descriptor builds its own copy of gn here/The linux
 descriptor builds its own copy of gn/
 >
 > s/the gn so build/the gn so built/

 Made a [https://gitweb.torproject.org/user/dcf/tor-browser-
 bundle.git/log/?h=snowflake-
 mac-6&id=faaeb294e36c233021bd2f4afa3d971bb3176c91 snowflake-mac-6] with
 [https://gitweb.torproject.org/user/dcf/tor-browser-bundle.git/diff/?h
 =snowflake-
 mac-6&id=faaeb294e36c233021bd2f4afa3d971bb3176c91&id2=f662c9cb1caea6348fe2dcb001d6600f2c813ae0
 those changes].

 > https://github.com/golang/go/issues/9206#issuecomment-310476743 is used
 for both path
 > and timestamp issue. It seems for the latter we want a different URL?

 That one URL illustrates both the timestamp and the path issues. It only
 talks about the path issue in the text, though. I couldn't find a more
 specific link for the timestamp issue. This part of the diff is due to a
 timestamp:
   {{{
   < 00333430  d4 15 4c 59 00 00 00 00  58 03 00 00 26 03 00 00
 |..LY....X...&...|
   ---
   > 00333430  dc 15 4c 59 00 00 00 00  58 03 00 00 26 03 00 00
 |..LY....X...&...|
   }}}
 This part of the diff is due to a path:
   {{{
   < 00359fe0  2f 67 6f 2d 6c 69 6e 6b  2d 34 34 37 31 39 35 39  |/go-
 link-4471959|
   < 00359ff0  38 34 2f 67 6f 2e 6f 00  72 75 6e 74 69 6d 65 2e
 |84/go.o.runtime.|
   ---
   > 00359fe0  2f 67 6f 2d 6c 69 6e 6b  2d 32 30 38 38 31 36 34  |/go-
 link-2088164|
   > 00359ff0  38 36 2f 67 6f 2e 6f 00  72 75 6e 74 69 6d 65 2e
 |86/go.o.runtime.|
   }}}

 > One thing I was wondering is whether it would be more beneficial to
 split up the big webrtc patch into
 > smaller ones. It might make it easier to follow the upstreaming efforts
 that way giving a clear impression on how many patches still need to get
 upstreamed and making patches easier to write once one or another of those
 patches is not needed anymore. I don't feel strongly about that, though.
 If you want to leave that as-is, fine with me.

 The patch actually is already split up into 8 smaller patches, each with
 their own commit message. They are just concatenated together into one
 file (i.e., in [https://git-scm.com/docs/git-am git am] format).

 > I have trouble to understand why `faketime` is needed now when building
 `go` given that we use `go` built without it for `obfs4proxy` and `meek`
 without any issues. "including those that arise here while compiling the
 Go runtime itself" should hold for the latter PTs as well, yet we don't
 need `faketime` in those cases. What is different between the `snowflake-
 client` and, say, the `obfs4proxy` case so that we need `faketime` for
 building `go` itself now? Are the problematic .o files plainly missing in
 `obfs4proxy`'s and `meek`s case? Or...

 I wondered about that too. I believe it is because of cgo. cgo invokes the
 system linker (i.e. Clang) and it is actually Clang that is the source of
 non-determinism, not go itself. See [https://dave.cheney.net/2016/01/18
 /cgo-is-not-go here] for example:
   When you `import "C"` in your Go package, `go build` has to do a lot
 more work to build your code. Building your package is no longer simply
 passing a list of all the `.go` files in scope to a single invocation of
 `go tool compile`, instead:
    * The cgo tool needs to be invoked to generate the C to Go and Go to C
 thunks and stubs.
    * Your system C compiler has to be invoked for every C file in the
 package.
    * The individual compilation units are combined together into a single
 .o file.
    * The resulting .o file take a trip through the system linker for fix-
 ups against shared objects they reference.

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


More information about the tbb-bugs mailing list