Following the addition of the GOINSECURE environment variable under #32966, it is now possible to select specific hosts to access insecurely when fetching dependencies. This is much neater than the -insecure flag currently supported by go get which will download insecurely for any host.
Given we now have GOINSECURE as of go 1.14, I propose the removal -insecure from go get.
34568 is also potentially relevant, presumably the issue with GIT_SSL_NO_VERIFY still exists when using GOINSECURE.
witchard
All 25 comments
CC @jayconrod @matloob @FiloSottile @katiehockman
bcmills
on 28 Feb 2020
I think we probably need to keep -insecure around long enough for folks to start using GOINSECURE (and report and work out any deficiencies with it), but I'd be happy to remove -insecure after that point ā say, in Go 1.16 (when every still-supported version of the Go toolchain will have GOINSECURE).
bcmills
on 28 Feb 2020
Does it make sense then to log something like ā-insecure will be deprecated soon, please consider using GOINSECUREā when someone uses the -insecure flag?
There is also the non-modules go get which doesnāt support GOINSECURE - https://github.com/golang/go/blob/master/src/cmd/go/internal/get/get.go#L391; is it worth back porting GOINSECURE into that or will that code disappear at some point?
witchard
on 28 Feb 2020
Does it make sense then to log something like ā-insecure will be deprecated soon, please consider using GOINSECUREā when someone uses the -insecure flag?
That's a very good idea. We could start doing that as soon as Go 1.15.
bcmills
on 4 Mar 2020
There is also the non-modules go get which doesnāt support GOINSECURE - https://github.com/golang/go/blob/master/src/cmd/go/internal/get/get.go#L391; is it worth back porting GOINSECURE into that or will that code disappear at some point?
Possibly both? It shouldn't be hard to retrofit GOINSECURE into GOPATH mode, but hopefully GOPATH mode will disappear in a _similar_ timeframe anyway.
bcmills
on 4 Mar 2020
I would be up for contributing to either / both of those. Should I change the proposal to focus on these features rather than deprecation?
witchard
on 5 Mar 2020
I think we should keep this issue focused on the proposed deprecation: we probably shouldn't warn about the flag if we aren't formally deprecating it, even if we decide to keep it for a while.
If you want to go ahead and send a CL for GOINSECURE in GOPATH mode, we can get that rolling independent of this proposal.
bcmills
on 6 Mar 2020
Ok great, should I open a proposal for that or is it fine just to work on it given itās providing feature parity with modules mode?
witchard
on 6 Mar 2020
Just a CL is fine.
bcmills
on 6 Mar 2020
It sounds like this is on hold for having GOINSECURE apply in GOPATH mode, although it's unclear to me that significant changes to GOPATH mode would be worthwhile at this point. Please change back to Active once it is appropriate to consider the deprecation again.
rsc
on 25 Mar 2020
I am intending on looking into GOINSECURE for GOPATH, but life and now this whole virus thing are getting in the way of my free time currently š. Iāll be sure to let you know once my free time is back on track!
witchard
on 25 Mar 2020
In #38108, @perillo notes that if and when we deprecate the -insecure flag, we should be sure to document the different behaviors w.r.t. the checksum database. -insecure today implies GOSUMDB=off, but GOINSECURE does not imply GONOSUMDB for the same modules.
bcmills
on 27 Mar 2020
Change https://golang.org/cl/229223 mentions this issue: cmd/go/internal/modget: improve GOINSECURE docs
gopherbot
on 21 Apr 2020
Change https://golang.org/cl/229758 mentions this issue: cmd/go/internal/get: add GOINSECURE support
gopherbot
on 23 Apr 2020
GOINSECURE is now supported in GOPATH mode, but I'm not sure if I can remove the proposal-hold label to open this back up?
witchard
on 2 Sep 2020
This was placed on hold until GOPATH supported GOINSECURE.
Now it does.
What do people think? Should we deprecate and then remove -insecure?
Perhaps deprecate (make it work but print a warning) in Go 1.16 and remove in Go 1.17?
rsc
on 16 Sep 2020
I think it makes sense to deprecate the -insecure flag in 1.16 and remove it in 1.17.
bcmills
on 16 Sep 2020
Change https://golang.org/cl/255882 mentions this issue: cmd/go/internal/get: warn about -insecure deprecation
gopherbot
on 19 Sep 2020
The deprecation warning is now merged :). Should we put something about it in the release notes for 1.16? What is the process for doing that, is it just a PR to edit https://github.com/golang/go/blob/master/doc/go1.16.html?
witchard
on 21 Sep 2020
Yep, exactly.
bcmills
on 21 Sep 2020
Change https://golang.org/cl/256419 mentions this issue: cmd/go/internal/get: add -insecure deprecation to release notes
gopherbot
on 22 Sep 2020
Based on the discussion above this seems like a likely accept.
(I see the code has already landed but might as well finish the process.)
rsc
on 23 Sep 2020
Yes, sorry about that! I got keen and put up the code changes because I didn't want to miss the code freeze.
witchard
on 24 Sep 2020
Change https://golang.org/cl/257157 mentions this issue: cmd/go/internal/get: improve -insecure deprecation docs
gopherbot
on 24 Sep 2020
No change in consensus, so accepted.
(@witchard, the code freeze is not for another month, for what it's worth.)
rsc
on 30 Sep 2020
Related issues
longzhizhi
Ā·
3Comments
dominikh
Ā·
3Comments
natefinch
Ā·
3Comments
go101
Ā·
3Comments
lkarlslund
Ā·
3Comments
Most helpful comment
This was placed on hold until GOPATH supported GOINSECURE.
Now it does.
What do people think? Should we deprecate and then remove -insecure?
Perhaps deprecate (make it work but print a warning) in Go 1.16 and remove in Go 1.17?