@dragonsinth Thank you. See if this works for you. Trivy appears to show this clears the outstanding vulns.

sweet, thank you!

What's your process to cut a release?

@gpassini just released 1.9.2

Thank you so much!

It still has some vulnerabilities, CVE-2024-24790 and CVE-2023-45285, which requires go upgrade to 1.21.11

Is there a plan to upgrade to 1.22 or 1.23?

@fivetran-ashokborra #494 (comment)

@fivetran-ashokborra Which scanner still detects these vulns in v1.9.2? I have tried Trivy and Grype and neither report these.

@nycnewman Google's container scanning API

@fivetran-ashokborra Just scanned grpcurl:1.9.2 docker image in Google Artifact scanner and it finds no vulnerabilities. 1.9.1 finds three.

These two are still shown in our scanning. These could be due to underlying go version

Interesting. I don't see that for the 1.9.2 image but do for the 1.9.1 image. The unscanned images are the in-toto attestation layers.

and the library in 1.9.2 is 1.23

Could you use go version 1.21 (same as the one defined in go.mod) to build the binary and let me know what you see?

@fivetran-ashokborra As requested, tested with 1.21 and it finds the following, which it also recommends usig 1.22 or 1.23 to resolve:

┌─────────┬────────────────┬──────────┬────────┬───────────────────┬────────────────┬─────────────────────────────────────────────────────────────┐
│ Library │ Vulnerability │ Severity │ Status │ Installed Version │ Fixed Version │ Title │
├─────────┼────────────────┼──────────┼────────┼───────────────────┼────────────────┼─────────────────────────────────────────────────────────────┤
│ stdlib │ CVE-2024-34156 │ HIGH │ fixed │ v1.21.13 │ 1.22.7, 1.23.1 │ encoding/gob: golang: Calling Decoder.Decode on a message │
│ │ │ │ │ │ │ which contains deeply nested structures... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-34156 │
│ ├────────────────┼──────────┤ │ │ ├─────────────────────────────────────────────────────────────┤
│ │ CVE-2024-34155 │ MEDIUM │ │ │ │ go/parser: golang: Calling any of the Parse functions │
│ │ │ │ │ │ │ containing deeply nested literals... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-34155 │
│ ├────────────────┤ │ │ │ ├─────────────────────────────────────────────────────────────┤
│ │ CVE-2024-34158 │ │ │ │ │ go/build/constraint: golang: Calling Parse on a "// +build" │
│ │ │ │ │ │ │ build tag line with... │
│ │ │ │ │ │ │ https://avd.aquasec.com/nvd/cve-2024-34158 │
└─────────┴────────────────┴──────────┴────────┴───────────────────┴────────────────┴───────────────────────────────────────────────────────

Interesting, these don't show up in our scanning results. I see the current go version defined is 1.21 in go.mod file of the latest code, how was the 1.9.2 binary built with 1.23?

@fivetran-ashokborra, the go.mod file only indicates the minimum version of Go for building from source. The Dockerfile indicates the actual version of Go used to build the binary that is in the container image pushed to Docker Hub:
https://github.com/fullstorydev/grpcurl/blob/master/Dockerfile#L1

Thanks @jhump that helps, we currently download the binary from here and run from /usr/local/bin directory. We will have to figure out alternative ways to use 1.9.2 with latest go version

hmm, I would have thought our release binaries would match our docker image in terms of toolchain...

@dragonsinth, I think you may need an env var to force this make step to use a newer toolchain: https://github.com/fullstorydev/grpcurl/blob/master/Makefile#L33

Something like GOTOOLCHAIN=1.23.4+auto. (Sadly, you must indicate a full toolchain version, not just a language version like "1.23".)

The issue is because releasing supports multiple platforms (including OS X of course) whereas Docker does not. So it uses a tool named goreleaser which uses the local Go toolchain to do cross compilation, instead of building everything inside a container. This unfortunately means it is less hermetic than the Docker builds. But the GOTOOLCHAIN env var can help remedy that.

One option to make them consistent would be to have the Dockerfile rely on the output of make release and have it just use the cross-compiled Linux version in the dist folder. However, that feels a little brittle -- if the commands were run in the wrong order, the Docker build might inadvertently pull a stale binary from a dist folder and publish it with the wrong version tag.

A possibly better option might be to move the Docker builds into goreleaser configs. Then the same make release could also build and publish the Docker images, and they'd be certain to be consistent between GitHub published artifacts and the Docker images.

Also, instead of using the GOTOOLCHAIN env var (and running the risk of someone running goreleaser without that set correctly), looks like you can set the toolchain to use directly in the goreleaser config.