Fails to build with a go.sum mismatch for the asynqmon project

[hiredman]

go-task build results in

verifying github.com/hibiken/asynqmon@v0.7.2: checksum mismatch
    downloaded: h1:EfLRppj5GlklMPzdCjdonpXz/D23meW0Pk6NAtkOPhw=
    go.sum:     h1:YohWgTIPwtMyZ6khBDcVUz9BdSdQW2Dxn8SoxtbmjSg=

SECURITY ERROR
This download does NOT match an earlier download recorded in go.sum.
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'.
task: Failed to run task "build": exit status 1

looks like this has been reported against the asynqmon project here https://github.com/hibiken/asynqmon/issues/318

My build script is somewhat atypical and looks like

podman container rm -f bitmanger-build
podman pull fedora:latest
podman container run -d --network host --name bitmanger-build fedora:latest sh -c 'mkfifo /tmp/block ; cat /tmp/block'
podman container exec -t bitmanger-build dnf install -y git go-task go
podman container exec -t bitmanger-build sh -c 'mkdir -p ~/go/src/github.com/bitmagnet-io/'
podman container exec -t bitmanger-build sh -c 'cd ~/go/src/github.com/bitmagnet-io/ && git clone https://github.com/bitmagnet-io/bitmagnet.git' 
podman container exec -t bitmanger-build sh -c 'cd ~/go/src/github.com/bitmagnet-io/bitmagnet && go-task build'
podman container exec -t bitmanger-build sh -c 'cd ~/go/src/github.com/bitmagnet-io/bitmagnet && POSTGRES_HOST=localhost POSTGRES_PASSWORD=postgres go-task migrate'
podman container cp bitmanger-build:/root/go/src/github.com/bitmagnet-io/bitmagnet/bitmagnet /tmp/bitmagnet
podman container rm -f bitmanger-build

and is creating a container based on fedora:latest, and building bitmagnet inside that container

[hiredman]

looks like go env -w GOPROXY=https://proxy.golang.org fixes it (fedora apparently defaults to direct?)

[mgdigital]

Hmm that's weird. I'm not sure I understand where the issue is - the Docker build in this repo is working, and the following works for me on fedora:latest (which would also have to pass all the checksums):

go install github.com/bitmagnet-io/bitmagnet@latest

Do you have some more minimal steps to reproduce this issue (preferably without podman :)?

[hiredman]

My immediate explanation for what is going on when the build failed with that checksum mismatch is the hibiken/asynqmon project changed the commit tagged with v0.7.2 some time after it was first used with https://proxy.golang.org, so now if you go through https://proxy.golang.org you get one commit and if you go direct you get a different commit, and the go.sum for bitmagnet-io has recorded the checksum you get when going through https://proxy.golang.org. That would explain why the build fails for me with GOPROXY=direct but succeeds with GOPROXY=https://proxy.golang.org. Looking at the ~/go/pkg/mod/github.com/hibiken/asynqmon\@v0.7.2/Dockerfile left behind by a successful build, it doesn't match the Dockerfile for the current v0.7.2 tag of asynqmon on github, which seems to confirm that this tag change happened.

The upstream go distribution (tarballs from go.dev) default GOPROXY to https://proxy.golang.org,direct and the golang container used in the Dockfile likely sticks pretty close to upstream, while fedora's go package defaults GOPROXY to direct. That might explain why the Dockerfile in this repo works, but hard to say because it is building bitmagnet a different way again, not calling go install or go-task, but directly invoking go build. The go build line it invokes looks similar to what go-task says it is invoking, but I am hardly an expert on go builds.

And not being an expert on go builds, I am at a loss to explain the difference in behavior between the go-task build (which says it runs go build -ldflags "-X github.com/bitmagnet-io/bitmagnet/internal/version.GitTag=$(git describe --tags --always --dirty)") and go install. If go install is bypassing go.sum checks that seems bad.

The reason I ended up using the go-task build is because the go-task stuff includes a way to run migrations, and it wasn't clear to me if they would get run otherwise. And I am running separate http_server and dht_crawler processes, and if migrations were run automatically at startup it was clear which would run them (I guess postgres has transactional ddl so maybe it doesn't matter?)

Which is all to say I am not sure this is so much a bug or something to fix with bitmagnet, but something hinky went on with one of its dependencies which may cause build issues.

[hiredman]

it looks like v0.7.2 hasn't been officially cut as a release in the asynqmon project, which is maybe why they felt comfortable changing the tag, however someone in the go ecosystem used asynqmon@latest somewhere, and v0.7.2 was the latest tag so it ended up cached in proxy.golang.org and sum.golang.org, but more changes came in and the asynqmon project moved the tag not thinking that anyone was already using it

[mgdigital]

Okay, lets give them a chance to fix it, if it hasn't been rectified by the next time we do a release I'll look at downgrading or specifying a commit hash rather than 0.7.2...