Dapr 1.7.0 checksum mismatch

[coreywagehoft]

Describe the bug

When using Dependabot to update dependencies it is currently failing due to an issue with the checksum for the 1.7.0 release with the following error:

verifying github.com/dapr/[email protected]: checksum mismatch

I found a related issue to this in dependabot-core: dependabot/dependabot-core#3073

To Reproduce

Use dependabot to manage go.mod dependencies in a repo that requires the Dapr go-sdk.

Expected behavior

The checksum should not fail and dependabot should be able to perform a dependency check.

[mikeb26]

I'm seeing the same problem without dependabot. I'm just doing a "go mod tidy" and I get:

        github.com/dapr/go-sdk/client: github.com/dapr/[email protected]: verifying module: checksum mismatch
        downloaded: h1:1ZTAzPisdNUP6qBfN4gqYxqgv4hQcH0+3rcSx+YS+3I=
        sum.golang.org: h1:SJC8layk2eKuJ8N+S84DtYpP4fgVugu8sUAliGu6/nM=

is there a workaround for this?

[coreywagehoft]

@mikeb26 most likely another release needs to be created for the dapr go-sdk as a patch version like 1.7.1.

Based on the issue I linked this could have been done if the git tag was moved after the GitHub release was created which is why the checksum mismatch is occurring.

[paulyuk]

@yaron2 this one was flagged to me as an issue that is causing a lot of pain for the devops process.

[yaron2]

I'll look into that but so far unable to reproduce it.

@mikeb26 can you try clearing your go cache and see if this resolves?

go ​clean -modcache

[mikeb26]

I'll look into that but so far unable to reproduce it.

@mikeb26 can you try clearing your go cache and see if this resolves?

go ​clean -modcache

I tried various versions of this along with building on a new installation of ubuntu and hit the same problem. It only seems to manifest when a go project has multiple sub-directories and multiple of those have dependencies on the dapr go sdk. I saw this once before last summer; I'm wondering if there's some release process of the dapr go sdk that can result in the problem @coreywagehoft postulates of the tag moving after release? the module vendoring system seems to be built on the assumption that released tags are immutable.

[coreywagehoft]

@yaron2 this is now occurring with the 1.8.0 release as well.

[jerbob92]

I also have this with 1.8.0 in Dependabot, even after clearing the caches locally and in our Dependabot setup

[gustavolimam]

Any updates on this issue?

[coreywagehoft]

@yaron2 are there any updates on this? This issue is causing dependabot to fail, hindering the ability to keep our dependencies up to date automatically.

[mikeb26]

@yaron2 any updates on this? hit again today on v1.9.1 after a go mod tidy:

$ GOPROXY=direct go mod tidy
...
go: finding module for package github.com/dapr/go-sdk/client
go: dapr/example imports
        github.com/dapr/go-sdk/client: github.com/dapr/[email protected]: verifying module: checksum mismatch
        downloaded: h1:SwfLYwqFwBNn1B8pCzGGG49utjV3oMQLZOlOkmf63T8=
        sum.golang.org: h1:f5gV8HtGz6iBJSsh6eI+/Ews4sGC3W9gX0/oD9ANVqM=

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