[tor-bugs] #28325 [Applications/Tor Browser]: Use go 1.11 module versioning support

[Tor Bug Tracker & Wiki]

#28325: Use go 1.11 module versioning support
-------------------------------------------+--------------------------
 Reporter:  boklm                          |          Owner:  boklm
     Type:  task                           |         Status:  assigned
 Priority:  High                           |      Milestone:
Component:  Applications/Tor Browser       |        Version:
 Severity:  Normal                         |     Resolution:
 Keywords:  tbb-rbm, TorBrowserTeam202002  |  Actual Points:
Parent ID:                                 |         Points:  3
 Reviewer:                                 |        Sponsor:
-------------------------------------------+--------------------------
Changes (by sysrqb):

 * keywords:  tbb-rbm, TorBrowserTeam202001 => tbb-rbm, TorBrowserTeam202002


Comment:

 Replying to [comment:9 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.

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

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