Golang: How to handle outdated dependency of google.golang.org/api on golang.org/x/net

Question content

Recently github.com dependabot complained that some dependencies in my project are vulnerable to DOS attacks and have "corrupt or risky Encryption Algorithm" and there is an "Uncontrolled Resource Consumption" error.

Specifically, it warned me about CVE-2022-27664 for the golang.org/x/net module, CVE-2022-27191 and CVE-2022-32149 for other modules.

What I did was run "go get -u" on all modules used. Obviously, this didn't solve the problem. Then I started using "go graph" to find module dependencies. It took a while and this is the order of dependencies I found:

google.golang.org/[email protected] =>
[email protected] =>
google.golang.org/[email protected] =>
github.com/envoyproxy/[email protected] =>
google.golang.org/[email protected] =>
golang.org/x/[email protected] =>
google.golang.org/[email protected] =>
golang.org/x/[email protected]

This means that the most modern and updated google.golang.org/api packages from March 17, 2023 will result in golang.org/x/ from 2018 net dependencies.

I found that other Google packages have a lot of dependencies on the old network module:

cloud.google.com/go/[email protected] golang.org/x/[email protected]
github.com/googleapis/gax-go/[email protected] golang.org/x/[email protected]
[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
golang.org/x/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]
google.golang.org/[email protected] golang.org/x/[email protected]

I checked the github.com/googleapis/google-api-go-client repository and found this issue https://github.com/googleapis/google-api-go-client/issues/1048 I said the same problem, but then user hashier said that since the go list -m all command shows the latest version, it's not a problem.

So, the main question is: is this a problem and why?

I just don't know what should be fixed here, github dependabot check or google-api-go-client module dependency.

Correct answer

It’s time to answer this question.

When I tried to check all the packages in the project one by one in a separate draft repository using go mod graph, these vulnerable dependencies came from another repository: github .com/go-gorm/postgres.

So, I incorrectly identified where the vulnerable dependency is coming from. Apparently this is due to the huge dependency graph:

[0] $ go mod graph | wc
    667    1334   56113

If anyone is looking for a way to visualize project dependencies, here it is:

go mod graph | modgv | dot -Tsvg -o graph.svg

Back to the original question. This is caused by github.com/go-gorm/postgres using an older version of go. As far as I understand, the only way to fix it is to upgrade the go version to 1.18. If the version is lower, go mod graph will show many vulnerable packages.

The above is the detailed content of Golang: How to handle outdated dependency of google.golang.org/api on golang.org/x/net. For more information, please follow other related articles on the PHP Chinese website!