Use go 1.11 module versioning support

[boklm]

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 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.

[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?

[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?

[cypherpunks]

​https://blog.golang.org/migrating-to-go-modules

[cohosh]

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 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.

[boklm]

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 vendor to fetch all dependencies, create a tarball of the vendor directory it created, then put the tarball online somewhere and use it as a dependency for the pion build.

[gk]

Let's pick this up for November/December.

[pili]

Assigning tickets to boklm for the next few months

[boklm]

It seems this issue is similar to #31588.

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 vendor and create a vendor tarball that we later use in the build.

[pili]

Moving tickets to December

[sysrqb]

Replying to boklm:

It seems this issue is similar to #31588.

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 vendor and 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.

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 vendor is 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.

[boklm]

An other option I think is to take the script dcf made for #28942 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_files section without creating them in the projects/ directory.

[sysrqb]

Release Train Migration.

[pili]

We are no longer in February, moving tickets

[pili]

We are no longer in March

[gk]

Okay, just for the dependency update I created #33953 to disentangle some pieces that got moved into this ticket, too.

[cypherpunks]

After upgrading to Go 1.14 only:
"Module support in the go command is now ready for production use"

[gaba]

Release all this tickets back into tbb-team.

[gk]

Add magic gitlab keyword.