x/vuln: incorrect fix version reporting GO-2023-1987, GO-2023-2041

[notrobpike]

What version of Go are you using (go version)?

$ go version
go version go1.20.6 darwin/amd64

Does this issue reproduce at the latest version of golang.org/x/vuln?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env
GOOS="darwin"
GOARCH="amd64"

What did you do?

when checking a package using crypto/tls (in my case go-redis but anything will do), using go1.20.6, govulncheck reports vuln GO-2023-1987. which is valid. except that it reports it fixed in go1.21rc4.

What did you expect to see?

the vuln is fixed in an earlier version, go1.20.7. i expected govulncheck to report that version. i often see govulncheck report the earliest version where a vuln is fixed, so i expected that here as well.

What did you see instead?

Vulnerability #1: GO-2023-1987
    Large RSA keys can cause high CPU usage in crypto/tls
  More info: https://pkg.go.dev/vuln/GO-2023-1987
  Standard library
    Found in: crypto/tls@go1.20.6
    Fixed in: crypto/tls@go1.21rc4

[cagedmantis]

cc @golang/vulndb

[zpavlinovic]

@tatianab

[notrobpike]

Also for the recent GO-2023-2041 and GO-2023-2043. Both report fixed in go1.21.1 but it's actually fixed earlier, in go1.20.8:

Vulnerability #2: GO-2023-2041
    Improper handling of HTML-like comments in script contexts in html/template
  More info: https://pkg.go.dev/vuln/GO-2023-2041
  Standard library
    Found in: html/template@go1.20.7
    Fixed in: html/template@go1.21.1

[zpavlinovic]

govulncheck's current approach is to always report the latest fix available.

I think that often the earliest and the latest fix coincide, so that is why you sometimes see what you described (unless there is a bug in the latest fix computation).

In your case, is there a particular reason why you would prefer the earliest instead of the latest fix?

[notrobpike]

govulncheck's current approach is to always report the latest fix available.

huh. then the language should perhaps be changed. "found in / fixed in" implies first known occurrence and first known fix. At least to this reader.

In this case, it's because it is implying a need to update the minor version (1.21.x) instead of just a patch version (1.20.x). In go, even "minor" version updates can introduce breaking behavior that needs to be fully tested/qualified, eg in go1.21 the initialization order is better defined and may be different. (compatbility promise aside).

Besides resistance to upgrading minor version "just" to address a vuln, the latest version tends to have more churn.

The "fixed in" version for the original report, GO-2023-1987, is an rc version! govunlcheck is suggesting me to update my codebase to an rc version? I think that would be ok if that were the only fixed version, but this was fixed earlier, in a go1.20 release version.

I think that generally speaking, it would be much more useful to report the first fixed version.

[gopherbot]

Change https://go.dev/cl/530679 mentions this issue: internal/scan: suggest earliest valid fixed version as the fix