1

Is it possible to avoid go build from pulling down a zip version of a specific dependency? The firewall blocks it and I can see that this could be a recurring theme. I can use git clone of the version and then copy it into the appropriate pkg folder, but this is a bit of a pain. Most packages are OK, just some seem to trigger 403 on firewall for the .zip. Changing firewall policy for specific zip is a longer term approach, looking for something to get going for now.

Details

Attempting to build a plugin for kong. The steps are:

  1. go mod init kong-go-plugin
  2. go get -d -v github.com/Kong/go-pluginserver
  3. go build github.com/Kong/go-pluginserver

This fails downloading one of the dependencies because the zip file is disallowed on the firewall.

...github.com/ugorji/go/codec@v1.1.7.zip:403 Forbidden

Update

The intention is not to subvert corporate firewall strategy and any of the proposed approaches should not be used to do so.

For context, in this case, the firewall, network, golang and kong are all experimental and I need to evaluate the solution before changing firewall policy. Also, the real/production firewall does actually allow this zip package, the experimental doesn't. If it is found that the blocked package is really deemed to be a vulnerability, then the firewall rule would need to be strengthened to disallow the github repo as well. Up until now we have only been using go get without mod and it worked fine, so I don't see that the suggested approach is an elevation in risk from what was in place before. Still, the point remains that any workarounds should not be used to subvert corporate firewall policy.

acarlon
  • 16,764
  • 7
  • 75
  • 94
  • 1
    The only workaround i can think of is not using go.mod, and use godep for dependency management. – Shubham Srivastava Sep 24 '20 at 04:11
  • 1
    I would love to know if there is a way of doing this with go mod; But moving to something like godep is old school way of dependency management using GOPATH – Shubham Srivastava Sep 24 '20 at 04:19
  • 4
    Setting [GOPRIVATE or GONOPROXY](https://golang.org/cmd/go/#hdr-Module_configuration_for_non_public_modules) to * should cause the go tool to always use the VCS to download code. – Peter Sep 24 '20 at 05:00
  • Thanks @Peter - those are both new to me, I will experiment and report back. – acarlon Sep 24 '20 at 11:50
  • @Peter, thanks GOPRIVATE solved it. It is only that specific package that has problem with firewall, so I set GOPRIVATE =github.com/ugorji/*. If you post as answer I will accept. Some background on GOPRIVATE might be good too. – acarlon Sep 24 '20 at 12:11
  • 2
    I would also suggest pinging your security folks. Either they have a bug in the rules, or they have a specific reason to not let people in your organization use that library. You should probably know which (and if it's a bug, letting them know is the first step to getting it fixed). – Charles Duffy Sep 24 '20 at 12:16
  • ...also, intentionally circumventing corporate security measures is frowned on, sometimes, and finding an alternate way to download a library that your infosec team has blocked (without first establishing that said behavior is accidental) could be argued to constitute such circumvention. – Charles Duffy Sep 24 '20 at 12:18
  • @CharlesDuffy you're assuming they've blocked that library explicitly, when OP has stated they block ZIP files in general. – Adrian Sep 24 '20 at 13:18
  • If that's the case, and they intend that the OP _should_ be able to download this specific zip file, it's a bug they should be able to adjust their rules to resolve. Notifying them remains the appropriate course of action. – Charles Duffy Sep 24 '20 at 16:06
  • @CharlesDuffy - see my update for context. Agree with the sentiment of not subverting corporate firewall policy. – acarlon Sep 24 '20 at 20:49
  • 1
    Gotcha. Personally, I use [Nix](https://nixos.org/) as my build system and package manager, thus use [`vgo2nix`](https://github.com/nix-community/vgo2nix) to build a listing of content for Nix itself to download and unpack into the GOPATH (as all builds in Nix where the output hash isn't known run in a sandbox with no network access, as part of a set of restrictions that help to ensure that a build output is a function of the stated/claimed inputs and nothing else); as a side effect, this means that Nix code modifying that environment can replace Go dependencies. – Charles Duffy Sep 24 '20 at 21:51
  • ...not really an approach I can reasonably suggest to someone else who isn't already using Nix, though. – Charles Duffy Sep 24 '20 at 21:51
  • @CharlesDuffy, thanks. Good to know. – acarlon Sep 24 '20 at 23:56

0 Answers0