Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

proposal: cmd/go: deprecate -insecure on go get #37519

Open
witchard opened this issue Feb 27, 2020 · 12 comments
Open

proposal: cmd/go: deprecate -insecure on go get #37519

witchard opened this issue Feb 27, 2020 · 12 comments

Comments

@witchard
Copy link
Contributor

@witchard witchard commented Feb 27, 2020

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 witchard changed the title cmd/go: Deprecate -insecure on go get cmd/go: deprecate -insecure on go get Feb 27, 2020
@bcmills bcmills changed the title cmd/go: deprecate -insecure on go get proposal: cmd/go: deprecate -insecure on go get Feb 28, 2020
@gopherbot gopherbot added this to the Proposal milestone Feb 28, 2020
@gopherbot gopherbot added the Proposal label Feb 28, 2020
@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Feb 28, 2020

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Feb 28, 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).

@witchard

This comment has been minimized.

Copy link
Contributor Author

@witchard witchard commented Feb 28, 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?

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Mar 4, 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

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Mar 4, 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.

@witchard

This comment has been minimized.

Copy link
Contributor Author

@witchard witchard commented Mar 5, 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?

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Mar 6, 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.

@witchard

This comment has been minimized.

Copy link
Contributor Author

@witchard witchard commented Mar 6, 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?

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Mar 6, 2020

Just a CL is fine.

@rsc

This comment has been minimized.

Copy link
Contributor

@rsc rsc commented Mar 25, 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 rsc moved this from Active to Hold in Proposals Mar 25, 2020
@witchard

This comment has been minimized.

Copy link
Contributor Author

@witchard witchard commented Mar 25, 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!

@bcmills

This comment has been minimized.

Copy link
Member

@bcmills bcmills commented Mar 27, 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants
You can’t perform that action at this time.