title: Avoid zip golang package
body: <p>Is it possible to avoid <code>go build</code> 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.</p>
  <p><strong>Details</strong></p>
  <p>Attempting to build a plugin for kong. The steps are:</p>
  <ol>
  <li><code>go mod init kong-go-plugin</code></li>
  <li><code>go get -d -v github.com/Kong/go-pluginserver</code></li>
  <li><code>go build github.com/Kong/go-pluginserver</code></li>
  </ol>
  <p>This fails downloading one of the dependencies because the zip file is disallowed on the firewall.</p>
  <blockquote>
  <p>...github.com/ugorji/go/codec@v1.1.7.zip:403 Forbidden</p>
  </blockquote>
  <p><strong>Update</strong></p>
  <p>The intention is not to subvert corporate firewall strategy and any of the proposed approaches should not be used to do so.</p>
  <p>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 <code>go get</code> without <code>mod</code> 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.</p>