Or it could be a stale module cache / hash generated with earlier go version.
Apparently there was a change in how hash was calculated.
I failed to create a reproducible by trying to force this. I created:

main.go:

package main

import (
	"fmt"
	_ "github.com/alecthomas/chroma"
)

func main() {
	fmt.Printf("Hello\n")
}

go.mod:

module tst

go 1.12

require github.com/alecthomas/chroma v0.6.5

And a repro.bat:

del /s /q go.sum
git config --unset-all core.autocrlf

git config --add core.autocrlf  true
git config --get core.autocrlf

go clean -modcache
go build .
copy go.sum go.sum1

del /s /q go.sum

git config --unset-all core.autocrlf
git config --add core.autocrlf false
git config --get core.autocrlf

go clean -modcache
go build .
copy go.sum go.sum2

The theory was to re-create go.sum with core.autocrlf=true and core.autocrlf=false but it seems in both cases I get the same:

github.com/alecthomas/chroma v0.6.5 h1:1gZ11dfxovHkbAM+xzyxjgxhG3Gr7U/cfOXI2eoEBkU=

But maybe I'm just not reproducing whatever git settings that led to creating:

github.com/alecthomas/chroma v0.6.5 h1:4CN9fmMfN/k6Ppb+djxJqu3BG7WuLkct0dvScOc0w2w=

One way to confirm the "format change" theory would be to rerun this with a version of go before the go.sum format change and see what hash it produces for github.com/alecthomas/chroma.

I don't know when this change happened.

There was a change in the way sums were calculated between go1.11.3 and go1.11.4 (we will ensure that never happens again). Is it possible the h1:4CN9... sum or the module it was derived from was from before that? Is there any way to reproduce this after cleaning the cache (go clean -modcache)?

The checksum algorithm explicitly sets core.autocrlf to avoid problems with line endings, so that shouldn't be an issue.

For the record, h1:1gZ11dfxovHkbAM+xzyxjgxhG3Gr7U/cfOXI2eoEBkU= is the correct sum (per sum.golang.org).

It's possible. I imagine running go build with go <1.11.3 on the sample program in #33178 (comment) and checking the checksum would resolve this for sure.

I don't have a setup with go 1.11.3 thought.

You can get Go 1.11.3 with go get golang.org/dl/go1.11.3 alongside your system Go.

It's still h1:1gZ11dfxovHkbAM+xzyxjgxhG3Gr7U/cfOXI2eoEBkU= with go 1.11 (as best as I can tell).

There was an earlier extraction bug (#27153) fixed in Go 1.11.2, and an even earlier one way back in the vgo phase (#26229). Any idea how old the module cache on your Windows machine is?

Also note that before Go 1.12, we had no locking or synchronization on the module cache. Is it possible that the cache entry for this module was corrupted due to concurrent go commands?

Yes, it's possible it comes from corrupted cache.

I've ran go clean -modcache since so no idea when that cache was corrupted.

It's fine to close this bug as I see no way to make progress determining the root cause.

Thanks. Do let us know if you see this again going forward, especially if you discover a clue as to the underlying cause.