2

We recently brought Golang into the company that I work in for general use, but we hit a snag in the roll out because Go can use the go get command to get packages from the internet. Typically when we roll out Java and Python we are able to limit where the developer can pull packages from by pointing them to our internal artifactory.

So with Python we can change where they pull from by altering the pip command to pull from our internal artifactory, and with Java we can alter their settings.xml and pom.xml to point to our internal packages.

I know that during development you can fetch and pull in dependencies into your local then compile them into a standalone binary. What i am looking for is some mechanism that stops people from going out and pulling from the open internet.

Does something like this exist in Go? Can I stop people from going to the internet and go get 'ing packages?

Any help would be greatly appreciated.

bR3nD4n
  • 111
  • 10
  • 2
    You can always [git clone your private repositories](https://golang.org/doc/faq#git_https) instead of using `go get`, and make that the expected way to do things on your team. – jrefior Mar 01 '18 at 06:47
  • 2
    Yes. Disconnect the workstations/laptops/servers. If your company allows git clone whats wrong with go get? – Volker Mar 01 '18 at 07:09
  • 2
    Possible duplicate of [How should I use vendor in Go 1.6?](https://stackoverflow.com/questions/37237036/how-should-i-use-vendor-in-go-1-6) – Jonathan Hall Mar 01 '18 at 07:59
  • 1
    `go get`'s entire purpose is to connect to the internet to get dependencies. If you don't want it to connect to the internet, don't use it. The other `go` commands do not require internet access. – Adrian Mar 01 '18 at 14:36

1 Answers1

3

It depends on your definition of "roll out", but typically there are three stages:

  1. Development - at this point you can't prevent arbitrary go get calls, apart from putting the development machines behind restrictive proxies or similar technical measures.
  2. Deployment - since Go programs can (should) be deployed as single binaries, go get is not used at all during deployment.
  3. Building deployment artefacts - this is probably your issue:

The usual approach is not to fetch dependencies when building Go programs. Instead, dependencies are fetched during development, and made part of the source tree using vendoring, for example by using the dep tool.

At this point, the build step no longer needs to fetch any dependencies. The choice of which dependencies are allowed now becomes part of the rest of your process, such as code reviews.

publysher
  • 11,214
  • 1
  • 23
  • 28
  • Ok, our packaging teams biggest issue is with the fact that in development they can go out to the internet and download any package then compile it into a single binary and we would not know what was in that binary potentially(company is over 10000, lots of people to manage) – bR3nD4n Mar 02 '18 at 14:51
  • @bR3nD4n You can run `go list -f '{{ .Deps }}' binary` to see the complete list of imported packages in that binary. You can also point it at a directory to see the complete list of imported packages in a source tree. – Michael Hampton Mar 02 '18 at 17:09