[Author Prev][Author Next][Thread Prev][Thread Next][Author Index][Thread Index]
Re: [tor-bugs] #22831 [Applications/Tor Browser]: Merge Snowflake for mac
#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
_______________________________________________
tor-bugs mailing list
tor-bugs@xxxxxxxxxxxxxxxxxxxx
https://lists.torproject.org/cgi-bin/mailman/listinfo/tor-bugs