resty: Verifying module, checksum mismatch (with new version 2.5.0)
I’m getting this error after upgrading from resty 2.4.0 to 2.5.0:
github.com/go-resty/resty/v2@v2.5.0: verifying module: checksum mismatch
downloaded: h1:GmCjQ7qW3Dzr3Lh7FvTrRJSWgYNWswDdOy+T8sgTAFI=
sum.golang.org: h1:WFb5bD49/85PO7WgAjZ+/TJQ+Ty1XOcWEfD1zIFCM1c=
SECURITY ERROR
This download does NOT match the one reported by the checksum server.
The bits may have been replaced on the origin server, or an attacker may
have intercepted the download attempt.
For more information, see 'go help module-auth'.
Already did:
go clean -modcache
go get -u ./... && go mod tidy
Any ideas? Thanks!
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Reactions: 9
- Comments: 28 (6 by maintainers)
I’m having the same issue in go 1.16.1 linux/amd64
after replacing GOPROXY from goproxy.io to goproxy.cn, the problem is solved.
Agreed. A new minor release should be done to fix the mess that has happened…
Is this going to be fixed? Faced the same issue on our self-hosted ‘athens’ proxy. The following tweaks helped:
after replacing GOPROXY from goproxy.io to goproxy.cn, the problem is solved.
Hello everyone - I understand and I’m sorry for the inconvenience. Before making release I have verified at my end (go1.15.6) it was looking good. I’m open to automation, no concerns. I will see to make 2.5.1 or I will go for the 2.6.0 release with few contributed enhancements.
Maybe the problem comes from goproxy curl -s https://goproxy.cn/gopkg.in/src-d/go-git.v4/@v/v4.13.1.mod | sha256sum &&
curl -s https://goproxy.io/gopkg.in/src-d/go-git.v4/@v/v4.13.1.mod | sha256sum &&
curl -s https://goproxy.baidu.com/gopkg.in/src-d/go-git.v4/@v/v4.13.1.mod | sha256sum &&
curl -s https://mirrors.aliyun.com/goproxy/gopkg.in/src-d/go-git.v4/@v/v4.13.1.mod | sha256sum
swith to goproxy.cn or other proxy
Seeing this also in our environment. Hits some users, not others, it’s something to do with local cache and the proxy. We’re using the default go mod proxy right now though I think we’ll eventually use artifactory.
Correct fix is to tag v2.5.1.
You should never delete a tag, make changes, then retag the same version.
If you want to mark a version as bad there’s a
retractoption for go.mod that lets you retract an earlier version, say, for security reasons.v2.6.0 release has been done. Please check
Changing the proxy or configuring GONOPROXY may seem like a desperate solution but is definitely not an acceptable fix. Like @IdanAdar mentioned previously, a new minor tag should be released to the public.
LGTM
same problem in go 1.16 macOS
Cc: @jeevatkm
We are seeing this in our build pipelines when using Go 1.15.8. Do we need to be concerned?
@jeevatkm Can you release 2.5.1? I assume you have released/tagged it, then it has been downloaded at least once so that the checksum got registered in the checksum db and then you recreated a release quickly to patch/fix something. Hence the mismatch.
@comartmit I thought about it, but there are few commits that happened for v2.6.0 dev iteration. That’s why couldn’t do a quick version bump. By tomorrow I will surely make v2.6.0 release.
How long does it take to release a new version with the correct checksums? Should I just fork-off?
y’know, I came across this article the other day talking about what the bug bounty hunter in question called dependency confusion (medium.com), which is more or less what we’re seeing here… Of course it’s possible someone force pushed (read: overwrote) a tag, but hey - maybe go-resty is one of a hand-picked few chosen to be part of a supply-chain attack POC against prominent US companies! There’s probably a badge for that.
Same issue here after updating the dependencies:
I’m getting (mostly) the same thing from dependabot -
…But then running
go mod downloadin CI:I noticed that dependabot PR’d the
GmChash, but then runninggo mod downloadin CI found theWFbhash. Not sure how dependabot does those updates…I encountered the same issue just now. any suggestions is appreciated. Thanks!