Thanks for your contribution! The first cve issue seems not related, the second one is about HTML, and the third one is about http2, all of this are not used by runc. We only use "golang.org/x/net/bpf" in runc.

Thanks for your contribution! The first cve issue seems not related, the second one is about HTML, and the third one is about http2, all of this are not used by runc. We only use "golang.org/x/net/bpf" in runc.

@lifubang It seems true. This report was output by me using trivy and may not be accurate.
At the same time, I saw that the net on main has been updated to v0.22.0. Does the release branch also need the same update?

I see runc main is using the versions you are updating to here, but I think we should update them to the latest, specially if we want to silence CVEs as 0.22 is vulnerable to some CVEs.

I'd update to the latest here and do the same in runc main too.

Also @kycheng can you comment how do you see a warning? Which tool are you using that throws a warning for this?

I'm using buildkit, the latest version of runc referenced by buildkit, and this issue was exposed when we scanned the buildkit(use trivy image ....).

With the recent supply chain attacks, I've verified locally that running "make vendor" with the changes on go.mod produces the exact same things as this PR. It's not a matter of not trusting you, but just to be on the safe side of things :)

In addition, the content of the vendor of this PR is indeed the same as that of make vendor. Sorry, I don't know what the process is. Do I need to remove the vendor changes and just update go.mod?

@rata

@kycheng Thanks!

In addition, the content of the vendor of this PR is indeed the same as that of make vendor. Sorry, I don't know what the process is. Do I need to remove the vendor changes and just update go.mod?

No, as it is is perfect. I was just letting maintainers know that there were indeed no hidden changes, as verifying that is needed to prevent some supply chain attacks. Nothing for you to change, just a sanity check :-)

The failure in the unit test seems to have nothing to do with my update. I spent some time understanding criu. Is the failure of the test related to the functions supported by the kernel?

I'm not quite sure how I can fix this unit test. @rata

You can just do git commit --amend and don't change anything, then push again. That will change the commit hash, so tests will run again, hopefully the flaky test passes now :)

@rata @AkihiroSuda Are there any other issues with this PR that need to be fixed? Can you help me review it?