Use go 1.11 module versioning support
Go 1.11 is adding preliminary support for Go modules, replacing the GOPATH-based approach.
obfs4 is adding go.mod and go.sum files, which use the Go modules support to fetch the dependencies. We disable that in #28310 (moved) as the go libraries we build are not currently recognized as Go modules.
We should change how we build our Go libraries so that they can be used as Go modules.
Activity
We could really use this for the snowflake reproducible build. Our solution to the Windows build issue is to use a different webrtc library (which will probably be less painful for us down the road anyway). However, that library has 30+ dependencies and is a pain to build right now (see https://trac.torproject.org/projects/tor/ticket/28942#comment:39).
Is this item roadmapped or is there some information on how difficult this task would be?
Trac:
Cc: N/A to cohosh
Replying to cohosh:
We could really use this for the snowflake reproducible build. Our solution to the Windows build issue is to use a different webrtc library (which will probably be less painful for us down the road anyway). However, that library has 30+ dependencies and is a pain to build right now (see https://trac.torproject.org/projects/tor/ticket/28942#comment:39).
Is this item roadmapped or is there some information on how difficult this task would be?
It's not roadmapped as we did not have any prio to do this so far. Not sure how difficult it would be but my guess it not too difficult. Is that ticket blocking you? Or, asked differently: by when would you need this solved?
-
Replying to gk:
Replying to cohosh:
We could really use this for the snowflake reproducible build. Our solution to the Windows build issue is to use a different webrtc library (which will probably be less painful for us down the road anyway). However, that library has 30+ dependencies and is a pain to build right now (see https://trac.torproject.org/projects/tor/ticket/28942#comment:39).
Is this item roadmapped or is there some information on how difficult this task would be?
It's not roadmapped as we did not have any prio to do this so far. Not sure how difficult it would be but my guess it not too difficult. Is that ticket blocking you? Or, asked differently: by when would you need this solved?
I'm still unfamiliar with what exactly we need for reproducible builds. If all we need is a commit hash for every go library that snowflake depends on, I could probably spend a day or two writing a messy build script for the pion go version of snowflake. It's annoying but doable.
I think the pion version is becoming more and more necessary given #31446 (moved) and us wanting to roll out support for windows users. So my answer is: if a hacky build script as described above would work, it's not necessary. If not, then we are blocked on this for moving away from the messy chromium webrtc sources.
I am still not sure how we should support fetching of sources for go modules in our build. In order to not block progress on using pion, if it has too many dependencies to manually create one project for each dependency, I think an other option is to run
go mod vendorto fetch all dependencies, create a tarball of thevendordirectory it created, then put the tarball online somewhere and use it as a dependency for the pion build.-
It seems this issue is similar to #31588 (moved).
One option to fix this would be to add a special build step where we allow network access in the container, and run
go mod vendorand create a vendor tarball that we later use in the build. Replying to boklm:
It seems this issue is similar to #31588 (moved).
One option to fix this would be to add a special build step where we allow network access in the container, and run
go mod vendorand create a vendor tarball that we later use in the build.I like this idea, and I think this is the easiest and most obvious solution. It should be reusable for rust, too.
[ticket:32027#comment:2 dcf]'s comment is useful here, as well.
This FAQ https://github.com/golang/go/wiki/Modules#how-do-i-use-vendoring-with-modules-is-vendoring-going-away and the entry two below it are helpful, too.
My main concern with this is it becomes difficult detecting when a sub-dependency (dependency-of-a-dependency) is modified. This should not be a problem, because the chain of hashes for each dependency should prevent this. However, I'd prefer a defense-in-depth approach and not take unnecessary risks. We can pin the expected hash of the vendored tarball, and we can at least detect when any of the files change (this is assuming the output from
go mod vendoris deterministic, of course), but it will require manual investigation to identify which dependency caused the failure.I'm moving this to February, but we should really, really implement a solution for this soon. boklm, I'm putting this on your plate, too.
Trac:
Keywords: TorBrowserTeam202001 deleted, TorBrowserTeam202002 added-
An other option I think is to take the script dcf made for #28942 (moved) and improve it: https://trac.torproject.org/projects/tor/attachment/ticket/28942/gomodtorbm
I think one possible improvement would be to define all go dependencies projects completely in the
input_filessection without creating them in theprojects/directory. 
Trac:
Parent: N/A to #33659 (moved)-
Okay, just for the dependency update I created #33953 (moved) to disentangle some pieces that got moved into this ticket, too.
-
Trac:
Sponsor: Sponsor58 to N/A
Parent: #33659 (moved) to N/A
Priority: High to Medium
Status: assigned to new mentioned in issue #28942 (moved)
mentioned in issue #29193 (moved)
mentioned in issue #31588 (moved)
mentioned in issue #32027 (moved)
mentioned in issue #33330 (moved)
mentioned in issue #33761 (moved)
mentioned in issue #33953 (moved)
mentioned in issue tpo/applications/tor-browser-build#33953 (closed)
