go: cmd/go: mod download doesn't allow insecure download

Please answer these questions before submitting your issue. Thanks!

What version of Go are you using (go version)?

go version go1.11 linux/amd64

Does this issue reproduce with the latest release?

What operating system and processor architecture are you using (go env)?

What did you do?

GO111MODULE=on go mod download

If possible, provide a recipe for reproducing the error.

error:

go: k8s.io/client-go@v8.0.0+incompatible: unrecognized import path “k8s.io/client-go” (https fetch: Get https://k8s.io/client-go?go-get=1: x509: certificate signed by unknown authority) go: k8s.io/api@v0.0.0-20180824172530-dd5c735cbff9: unrecognized import path “k8s.io/api” (https fetch: Get https://k8s.io/api?go-get=1: x509: certificate signed by unknown authority)

A complete runnable program is good. A link on play.golang.org is best.

What did you expect to see?

What did you see instead?

About this issue

  • Original URL
  • State: closed
  • Created 6 years ago
  • Reactions: 16
  • Comments: 56 (22 by maintainers)

Most upvoted comments

Disappointed to see this request being closed. Many large enterprises don’t manage certificates ideally for a variety of reasons. Very often developers in those environments don’t have enough authority or influence to change how those enterprises manage certificates.

I understand the reluctance to introduce a flag allowing users to disable part of TLS is not ideal, but reality is often not ideal. This is precisely why most tools include a -insecure flag of some sort to allow those in less than ideal environments to use the tool. Not including this flag in an effort to make the world safer is a noble ideal, but ultimately just makes life more difficult for those developers who don’t have the ability to change their environments.

Hopefully this decision is reconsidered and the -insecure flag is added to go mod vendor. Tools like this should be focused on delivering functionality in any environment. Again, it’s noble to take advantage of the leverage you have as tool maintainers to make the world a better place. However, it’s also okay to allow institutions and users to decide for themselves how they want to manage risk.

I vote to close this as “works as designed”.

All I wanted for Christmas was the --insecure flag.

(Or, to put it another way: I would prefer that we deprecate the -insecure flag rather than expanding its reach.)

A global flag defeating all security is uncomfortable because users will naturally use it and go on with their day instead of reporting the specific reason they need it, which we might be able to address safely. Remember that modules support is still in experimental state, so now is the time to learn. For example:

  • if we are failing to recognize an installed root CA, like in #24652, we should fix that
  • if users need to use external root CAs more easily, a proposal to add an environment variable to add them to the pool without installing them might make sense
  • if internal insecure modules (http:// or git://) are widespread, we might consider a bypass list in a config file the same way we will have an exclude list for internal modules that should not be fetched from the mirror; this critically only defeats security for some modules, maybe the ones that are fetched over a VPN anyway; or maybe this need will be addressed by a GOPROXY implementation that will have much better flexibility in authentication methods than we could ever provide in the go tool.

If any of the above seem to match your use case (or not), please open a specific issue with as many details as possible of what you are trying to do and in what environment (not just the solution you want) and tag me and @bcmills. I am closing this issue to encourage per-scenario discussion, not because there are no valid use cases here.

(If instead you do indeed need to defeat all security because of some security appliance, sounds like you should bring that up as an issue with your vendor as soon as possible.)

How many people would need the full -insecure shotgun, and why, as opposed to an environment variable to point to a private CA (cough) or self-signed certificate to trust?

example1: in some company, use private Gitlab env, just use http and ssh, no https

How many people would need the full -insecure shotgun, and why, as opposed to an environment variable to point to a private CA (cough) or self-signed certificate to trust?

Seems to me this boils down to “Our Gitlab server has an invalid TLS certificate, so please disable security for every Go user in the world so we don’t have to fix our certificate”.

need -insecure

We have our own CA and must go through a corporate proxy. Unless I want to install our CA on every docker image I pull, I usually use an -insecure flag. The fact that go mod download doesn’t support this is not cool. Now in order to run go mod download I have to disconnect from our VPN, run the command and then get back onto our VPN which is a waste of at least 2-3 minutes each time.

We are dealing with this problem as well. An -insecure flag would be very helpful.

@berniedurfee-ge We should write to the head of the golang project at google. Low level engineers dont see the big picture.

Why is there such a problem, what is the cause of this problem? thanks

It is how https works. The client has to verify the cert returned by the server. We can explicitly choose to ignore validating the cert. go get has an option to allow that, go mod download doesn’t. Hence the issue.

I have an alternative solution but I can understand the dilemma some of these developers find themselves in.

Maybe I don’t understand why this is such an issue to add a flag to give support to the community that needs it in order to continue down the path that was given. Make this an optional flag or at least supply a fix that will allow those that need it as a way to progress that is realistic.

I’ve never seen such push back on something that would be so simple to address. Is this push back just due to not wanting to do something or just to get developers of the Go project riled up? At this point it just seems antagonistic which is just the opposite of what I’ve seen and experienced in the Go community, I hope this simple request can be resolved in a friendlier manner.

but they would have to deal with the certificates pain

Setting up a private CA is practically a breeze with mkcert or various other tools out there. The entire world is moving to https. There are various web features (like SWs) which are not available on http at all.

What @bcmills and @FiloSottile are trying to understand is why folks are unable to move to https. And so far the answer is that “certificate pain”.

I may have minimal experience on this, so @FiloSottile can chime in, but installing a private CA takes no time at all. And for external servers, you have letsencrypt. Although I agree that one has to still ramp up on these tools and in some corporate environments, there are levels of red tape. So it is not always a one command install.

A tough call.

I can’t convince IT (a private gitlab cluster with hundreds of servers deployed in different cities, I don’t know what the actual risk on the production environment), just as I can’t convince you. glide can help me go mod can’t Sorry, I shut up.

From the discussion on the CL:

it sounds like most of the cases where this would be useful are cases where go get is missing a root certificate for the requested domain.

I’d prefer that we address that case directly rather than adding a bypass flag: we don’t really want folks to put -insecure in their GOFLAGS and end up downloading and running untrusted code.

Nothing to do with antagonism or being unfriendly; it’s a security issue. Using HTTPS links without actually checking the certificates gives a false sense of security. If you can’t set up a verifiable TLS cert chain, you should be using a non-HTTPS URL, to make it clear that this is not a secure connection.

I’ve never seen such push back on something that would be so simple to address.

Then perhaps there’s a good reason.

When you have hundreds of certificates (=> a few expiring every single day) and thousands of developers, then the breeze becomes a hurricane.

Seconding this. My work has a number of internal gitlab instances with self-signed certs. An -insecure flag would be very helpful.

They also have to want.

Enforcing TLS should always be a consumer choice. Some organizations don’t see the benefits of having internal TLS but they would have to deal with the certificates pain

I see in the recent change the flag has been added will this also allow it to pick up the setting in GO_FLAGS like other commands can?

i.e. GOFLAGS=-insecure

How about allowing an optional, non default —insecure flag? For those in environments where go mod won’t work. Seems like it would help some and hurt no one.

@andesli, see http://golang.org/wiki/NoPlusOne.

(Also note that this issue is closed, and we have no process in place to follow up on closed issues.)

I filed a related issue this weekend #29059

That’s a case where we should (and will) fix the underlying issue, not provide -insecure as a workaround.

I vote for this.

I filed a related issue this weekend #29059

vote +1

the big private gitlab is controlled by IT

So why can’t your IT department obtain and deploy an appropriate certificate for HTTPS?

IT said, “inner use ssh for speed, they don’t see the benefits of having internal TLS but they would have to deal with the certificates pain”

I want insecure option just for can get the meta data https://gitlab.innerdomain.com/org1/repo?go-get=1 then use git urlInsteadOf option

git config --global url."ssh://git@gitlab-ti.innerdomain.com:2222/".insteadOf "http://gitlab-ti.innerdomain.com/"
git config --global url."ssh://git@gitlab-ny.innerdomain.com:2222/".insteadOf "http://gitlab-ny.innerdomain.com/"

@Haiyung This issue is closed. Also, please see https://golang.org/wiki/NoPlusOne. Thanks.

Agree, however an -insecure option would have given me a workaround for the meantime.