go-tools: Wrong certificate on honnef.co
I have an issue with dependency scanning of my repo which implicitly using your extension. The extension itself is working but scanning doesn’t pass:
honnef.co/go/tools@v0.0.0-20190102054323-c2f93a96b099: unrecognized import path "honnef.co/go/tools" (https fetch: Get https://honnef.co/go/tools?go-get=1: x509: certificate is valid for *.netlify.com, netlify.com, not honnef.co)
Can it be that something is wrong with certificate of your website?
Thanks for your attention.
About this issue
- Original URL
- State: closed
- Created 5 years ago
- Reactions: 62
- Comments: 30 (3 by maintainers)
Commits related to this issue
- fix(svcop): fix broken upstream for honnef.co See https://github.com/dominikh/go-tools/issues/658 The upstream for this module is borked, but we can go direct to github — committed to alphagov/gsp by philandstuff 5 years ago
- fix(node-lifecycle-hook): fix broken upstream for honnef.co See https://github.com/dominikh/go-tools/issues/658 The upstream for this module is borked, but we can go direct to github — committed to alphagov/gsp by philandstuff 5 years ago
I’ll summarize the situation:
An incorrect change in DNS caused the domain
honnef.coto point to the wrong server, which wasn’t yet fully set up for serving the domain, in particular thego getendpoints. For HTTPS, this manifested itself in an invalid TLS certificate. For HTTP, this manifested itself in a 404 error.Anyone who is using the Go module proxy – which Go 1.13 uses by default – or who got lucky and never had their DNS servers see the incorrect update, will not have encountered this issue.
For anyone else, the issue will fully resolve itself once DNS has propagated the fixed records. If you are using modules, consider using the module proxy – it was in part designed to avoid situations like these. Alternately, you can employ go.mod’s
replacedirective as a temporary workaround, to obtain sources directly from GitHub.Edit: in the interim, Netlify decided to provision a LetsEncrypt certificate for the domain, which is why people are now encountering the “no go-import meta tags” issue instead of the TLS issue. Still waiting for DNS to update, and making sure our original certificate keeps working in the meantime.
This was a temporary mis-configuration of DNS. The fix should be propagating as we speak.
Highly recommend using GOPROXY to prevent these type of things to happen. Look into this https://arslan.io/2019/08/02/why-you-should-use-a-go-module-proxy/
I had to use
GOPROXY=https://proxy.golang.org go build ...to get it to workPutting
replace honnef.co/go/tools => github.com/dominikh/go-tools v0.0.0-20190102054323-c2f93a96b099into thego.modfile fixed the issue for me@teefax I wouldn’t recommend changing the mod file directly, as tidy and verify
go modcommands might overwrite it. Use GOPROXY instead. GOPROXY is designed to handle this type of situations.I’ve got this now : go: honnef.co/go/tools@v0.0.0-20190102054323-c2f93a96b099: unrecognized import path “honnef.co/go/tools” (parse https://honnef.co/go/tools?go-get=1: no go-import meta tags ())
Hopefully it is working for everyone again. I am going to close this issue. Again my apologies for breaking your builds.
Works for us. Thanks for resolving this quickly.
@alinz GOPROXY didn’t work for me immediately, but it is now. I’m not sure if it’s because of local caching or not.
@dominikh thank you for the quick fix and advice; I’ll update my environment to use the go proxy by default until I’m at 1.13 across all projects.
Working for me on go 1.13 (which runs on the proxy by default)