cmd/go: all commands that can fetch dependencies should accept the insecure flag

[rogpeppe]

go version devel +2e4edf4697 Sun May 12 07:14:09 2019 +0000 linux/amd64

When trying to work around issue #32071, I realised that although almost all of the go subcommands can download dependencies now, you can't allow insecure fetching.
The go get command supports insecure fetching but there's no easy way to make it use the version specified in the current module AFAICS.

Alternatively, it may be sufficient just to add an insecure flag to go mod download.

[bcmills]

See previously #27332 (comment) (CC @FiloSottile @jayconrod).

[bcmills]

I really don't want people putting -insecure in their GOFLAGS and ending up doing insecure fetches when they run go build or go test.

I could maybe buy the need for a -insecure flag to go mod download, but I would want to see some compelling concrete reasons for it. (This specific GitHub bug seems likely to either be resolved soon on the GitHub side or receive a workaround in the go command itself, so it doesn't seem all that compelling — and note that you can always clone your dependency by whatever means you like and use an explicit replace directive to relocate it.)

[rogpeppe]

AFAICS, if go get has an -insecure flag, then go mod download should too. The insecure download is probably more dubious in go get tbh because that more often gets non-sum-checked dependencies, whereas go mod download is more likely to check everything with an existing go.sum file.

I guess it might be possible to allow insecure downloads only if the download can be fully checked by a local go.sum file.

[witchard]

How about a GOINSECURE env variable similar to GONOPROXY and GONOSUMDB (https://go.googlesource.com/proposal/+/master/design/25530-sumdb.md). That way you could selectively disable https for specific urls, and remain secure by default?

[FiloSottile]

I tend to agree much more with a GOINSECURE env var rather than a universal flag. These is no good reason to fetch every module insecurely just because one does not support HTTPS.

Please open a proposal issue for GOINSECURE.

-insecure made a little more sense before modules, when you were often fetching a main package, and only used go get for it, but these days any command might fetch any dependency, so a single insecure module would have to poison every go invocation. I think we should deprecate go get -insecure.

[bcmills]

As of Go 1.14, all command that can fetch dependencies should now support the GOINSECURE environment variable. (Please open a new issue if you find that is not the case.)

Given GOINSECURE, I suspect that we do not need to add the less-precise -insecure flag.

@rogpeppe, do you have any remaining use-cases that GOINSECURE does not address?

[rogpeppe]

@bcmills not that i've found. thanks for addressing this!

[bcmills]

Closing as obsoleted by #32966. (Thanks, @witchard!)