github.com/firefart/nonamedreturns@v1.0.0: verifying module: checksum mismatch

[joewreschnig]

Hi,

The checksum for this module currently in the module proxy does not match the checksum I get when I try to pull from the repository. This is probably not affecting most people because they use both the official Go proxy cache and official checksum database, but I am trying to populate a local proxy cache cache.

$ GOPROXY=direct go install github.com/firefart/nonamedreturns@v1.0.0
go: downloading github.com/firefart/nonamedreturns v1.0.0
go: github.com/firefart/nonamedreturns@v1.0.0: github.com/firefart/nonamedreturns@v1.0.0: verifying module: checksum mismatch
	downloaded: h1:bP/nIE/jZyMFBIH3LQp5vwqCO4/+Lftxu+DXqRh/3aQ=
	sum.golang.org: h1:TKZUsLIQ7rks6+g5qdG+MAtMIvZEvVSYGNDeybB7jO0=

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'.

Did you rebase or retag v1.0.0 in the past?

[firefart]

yes v1.0.0 was deleted and recreated

[joewreschnig]

Please tag a v1.0.1 ASAP and have golangci-lint update to it, as this is currently breaking their build. Version tags in Go modules are immutable; you can never change what they point to without triggering checksum violations.

[firefart]

there is now a version v1.0.1 if you wanna use it

[ldez]

@firefart can you explain why you did that? Because it's a real problem for us.

As explained by @joewreschnig, tags in Go modules are immutable, and when you do that you have a security impact on golangci-lint.

I can understand that you didn't know that and we will assume the consequences.

[firefart]

because you requested multiple changes and I didn't want to create new versions for each of them. See here for the update PR: golangci/golangci-lint#2776

[ldez]

Ok, I can understand.

We are lucky that someone has detected the problem before a release, thank you @joewreschnig.
I need to find a way to enforce the check of this kind of problem during the review process.

[joewreschnig]

Thanks @firefart and @ldez for addressing this so quickly!

Regarding enforcing this during review, a build/test run with GOPROXY=direct will usually detect this.

Regarding workflow for changes during a PR, in situations like this our team usually keeps the go.mod version pointing to specific revisions (e.g. a version like v0.0.0-20220325145130-11b0aca896bd) during code review, tagging only after review is finished before merging. Repointing the tag after changes doesn't work right anyway, since the depending project will usually keep pulling the same code over the proxy every time.