v1.8.5 includes version of golang.org/x/text which flags our CVE scanner

[jeffwidman]

We install grpcurl as a binary in some tooling.

However, our security team just added some CVE scanners that fail the build if known CVE's are found.

grpcurl is throwing the following:

+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
41s
996|      LIBRARY      | VULNERABILITY ID | SEVERITY | INSTALLED VERSION | FIXED VERSION |                 TITLE                 |
41s
997+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+
41s
998| golang.org/x/text | CVE-2020-14040   | HIGH     | v0.3.2            | 0.3.3         | golang.org/x/text: possibility        |
41s
999|                   |                  |          |                   |               | to trigger an infinite loop in        |
41s
1000|                   |                  |          |                   |               | encoding/unicode could lead to...     |
41s
1001|                   |                  |          |                   |               | -->avd.aquasec.com/nvd/cve-2020-14040 |
41s
1002+-------------------+------------------+----------+-------------------+---------------+---------------------------------------+

My hunch is that this is likely due to some outdated deps, and pulling in #267 could quickly fix. I haven't walked the full dep tree though, so perhaps even then this wouldn't be fully fixed and would require adding an //indirect pin that bumps past this broken one.

There's actually another CVE in golang.org/x/text@0.3.6, so might be best to just pin to v0.3.7 to avoid this recurring in the future.

[jeffwidman]

Oof, we added an //indirect pin internally to bump golang.org/x/text past this, but the scanner is still complaining... aquasecurity/trivy#1559.

I suspect it's somehow scanning the go.sum file so that even if the compiled code doesn't actually include the vulnerable code, it'll still be reported as a false positive. 🤦‍♂️

[jhump]

even if the compiled code doesn't actually include the vulnerable code, it'll still be reported as a false positive

I've definitely had this issue before. Sometimes go mod tidy will help, to clean up old records from go.sum. But go.sum, even tidied, can have multiple versions of the same module, even though only one is actually compiled and linked in (it checksums every referenced dependency in the graph, including indirectly referenced versions that will actually be unused in the build).

[jeffwidman]

Yeah, go mod tidy -compat=1.17 helps, we dropped thousands of lines from some of our go.sum files. 😀

But still be nice to pin to newer version here in grpcurl.