feat(image): goversion as stdlib

[thepwagner]

Description

Modify the golang/binary parser to emit the version of the golang runtime as stdlib.

The purl generated by this name is compatible to what is produced by syft, but I don't think it will be useful for vulnerability matching. Grype's strategy seems to be CPE matching.

My goal is to make the go runtime version visible when reporting in the CycloneDX format. This is motivated by 2024-03-05 release: https://groups.google.com/g/golang-announce/c/5pwGVUPoMbg

Related issues

• Close Golang stdlib vulnerabilities #4133

Checklist

• I've read the guidelines for contributing to this repository.
• I've followed the conventions in the PR title.
• I've added tests that prove my fix is effective or that my feature works.
• I've updated the documentation with the relevant information (if needed).
  • N/A(?)
• I've added usage information (if the PR introduces new options)
  • N/A
• I've included a "before" and "after" example to the description (if the PR is a user interface change).
  • N/A

[CLAassistant]

All committers have signed the CLA.

[CLAassistant]

Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.
_{You have signed the CLA already but the status is still pending? Let us recheck it.}

[thepwagner]

👋 it's been a little over a month - are you able to provide any feedback? Thanks!

[itaysk]

@thepwagner thanks for the contribution! some of the maintainers are away this week, we will try to look at it soon after returning.

[knqyf263]

Thanks for your contribution. OSV uses toolchain rather than stdlib. I think it's better to get aligned with them.

curl -s "https://api.osv.dev/v1/vulns/GO-2021-0068" | jq '.affected[].package'
{
  "name": "toolchain",
  "ecosystem": "Go",
  "purl": "pkg:golang/toolchain"
}

[knqyf263]

Hmm. But they also use stdlib.

$ curl -s "https://api.osv.dev/v1/vulns/GO-2024-2687" | jq ".affected[].package"
{
  "name": "stdlib",
  "ecosystem": "Go",
  "purl": "pkg:golang/stdlib"
}
{
  "name": "golang.org/x/net",
  "ecosystem": "Go",
  "purl": "pkg:golang/golang.org/x/net"
}

[knqyf263]

It seems like they use toolchain for cmd/go. In this case, stdlib looks better.

BTW, I don't know why the tests were not triggered. I'll merge the main branch and see if it triggers the tests.

[cbandy]

📝 Go versions prior to 1.21 did an unusual thing with their version numbers. It probably won't matter now that those all have patches and 1.20 is not supported.

https://go.dev/doc/go1.21

Go 1.21 introduces a small change to the numbering of releases. In the past, we used Go 1.N to refer to both the overall Go language version and release family as well as the first release in that family. Starting in Go 1.21, the first release is now Go 1.N.0.

[knqyf263]

Trivy expects semantic versions in Go. It may show warnings with binaries compiled Go prior to 1.21, but I believe it won't stop scanning. Let's see.