go-sqlite3 checksum mismatch when running ./update-deps.sh

[runcom]

Nature of the bug

Running ./update-deps.sh on a freshly clone errors out with checksum mismatch when verifying go-sqlite3

Steps taken to find bug

just run ./update-deps.sh
the "fix" for me is to remove go.sum and re-run again - only to have a different hash in go.sum though

Steps to ensure bug is gone

no error

Optional: Reproduction

Just run ./update-deps.sh, my system spec are as follow:

➜  go-fdo-server git:(main) ./update-deps.sh 
verifying github.com/ncruces/go-sqlite3@v0.20.0: checksum mismatch
	downloaded: h1:iY9wQUVvfcWVmwFvHcO1CmjzCyssiO3sBu1IOxdUND0=
	go.sum:     h1:/nBLvYxj7sk9S6y57nmMFvoQ/KJtGo0pNi8J80s8oJU=

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'.
verifying github.com/ncruces/go-sqlite3@v0.20.0: checksum mismatch
	downloaded: h1:iY9wQUVvfcWVmwFvHcO1CmjzCyssiO3sBu1IOxdUND0=
	go.sum:     h1:/nBLvYxj7sk9S6y57nmMFvoQ/KJtGo0pNi8J80s8oJU=

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'.
Dependencies updated and go.mod tidied up.
➜  go-fdo-server git:(main) go version
go version go1.23.2 linux/amd64
➜  go-fdo-server git:(main) cat /etc/os-release 
NAME="Fedora Linux"
VERSION="41 (Workstation Edition)"
RELEASE_TYPE=stable
ID=fedora
VERSION_ID=41
VERSION_CODENAME=""
PLATFORM_ID="platform:f41"
PRETTY_NAME="Fedora Linux 41 (Workstation Edition)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:41"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f41/system-administrators-guide/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://bugzilla.redhat.com/"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=41
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=41
SUPPORT_END=2025-05-13
VARIANT="Workstation Edition"
VARIANT_ID=workstation

[runcom]

The same happens when building in the container

[1/2] STEP 1/5: FROM golang:1.23-alpine AS builder
✔ docker.io/library/golang:1.23-alpine
Trying to pull docker.io/library/golang:1.23-alpine...
Getting image source signatures
Copying blob 4f4fb700ef54 done   | 
Copying blob 43c4264eed91 done   | 
Copying blob 4cc291be95ef done   | 
Copying blob 5c3c966382ef done   | 
Copying blob 2ac1f1163629 done   | 
Copying config 5a72c8b953 done   | 
Writing manifest to image destination
[1/2] STEP 2/5: WORKDIR /app
--> c845662c5973
[1/2] STEP 3/5: COPY . .
--> 551d8e0e6636
[1/2] STEP 4/5: RUN go mod download
verifying github.com/ncruces/go-sqlite3@v0.20.0: checksum mismatch
	downloaded: h1:/nBLvYxj7sk9S6y57nmMFvoQ/KJtGo0pNi8J80s8oJU=
	go.sum:     h1:iY9wQUVvfcWVmwFvHcO1CmjzCyssiO3sBu1IOxdUND0=

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'.
Error: building at STEP "RUN go mod download": while running runtime: exit status 1
make: *** [Makefile:24: build] Error 1

[ben-krieger]

Perhaps the library in question had its tag changed to another commit between the time the go.sum in this repo was created and now. If so, it's a valid warning. But I'd just ignore it. Delete the go.sum and try again.

[runcom]

Perhaps the library in question had its tag changed to another commit between the time the go.sum in this repo was created and now. If so, it's a valid warning. But I'd just ignore it. Delete the go.sum and try again.

yeah, my point is, should I just commit the updated go.sum? as right now, you can't just checkout the project, build and run

[ncruces]

If that's what happened, it's incredibly unfortunate.

I sometimes do that, when something in the artifact attestation fails in the release process.

I wanna have have something like this that attests that the Wasm files at tag v0.21.1 have those SHA256 hashes.

But for that to happen I need to push a tag to GitHub, which you can fetch at the exactly wrong time. But it's usually a couple of minutes for the attestation process to complete, and it usually succeeds.

[ben-krieger]

If that's what happened, it's incredibly unfortunate.

I sometimes do that, when something in the artifact attestation fails in the release process.

I wanna have have something like this that attests that the Wasm files at tag v0.21.1 have those SHA256 hashes.

But for that to happen I need to push a tag to GitHub, which you can fetch at the exactly wrong time. But it's usually a couple of minutes for the attestation process to complete, and it usually succeeds.

Yeah, if that's what happened it's just bad luck due to the small window for it to occur. And I don't think it's a big deal, because there's enough re-tagging in the wild that this problem is understandable and Google-able.

But there's also a chance that the issue is unrelated. I've seen, at least once, issues with our corporate proxy where Go module checksums end up not matching compared to off the VPN. I never figured it out exactly, but I think it happens when the module is pulled with git instead of a tarball download and usually there are git submodules involved.

All that said, if anyone is using this project, please feel free to fix the checksum and open a PR.

[ben-krieger]

This should be fixed with 6b6c1b0

[runcom]

still happening unfortunately:

verifying github.com/ncruces/go-sqlite3@v0.21.3: checksum mismatch
downloaded: h1:wPzscgKHpRKSIjEy1sFWX0X2Xs26gszHCBMo7SJGgo0=
go.sum: h1:hHkfNQLcbnxPJZhC/RGw9SwP3bfkv/Y0xUHWsr1CdMQ=

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

[ncruces]

It shouldn't. Please see ncruces/go-sqlite3#209 for the actual cause and fix.

PS: you may need to update to v0.22.0 @ben-krieger.

[ben-krieger]

Updated the deps in main.

@runcom What's the output of go env GOPROXY for you and have you run git lfs install?

[ncruces]

Note that @runcom's hashes match the bug in my repo for version v0.21.3. So this must be the underlying issue:

• whatever configuration @runcom is using downloads Git LFS artifacts
• the "official" Go proxy does not have LFS, so doesn't download them

Sorry. It didn't occur to me to update this bug when that one was opened/closed.