vendor: google.golang.org/grpc v1.56.3

[thaJeztah]

• relates to vendor: golang.org/x/net v0.17.0 #4340

---

vendor: google.golang.org/grpc v1.56.2

full diff:

• grpc/grpc-go@v1.53.0...v1.56.2
• googleapis/go-genproto@7f2fa6f...daa745c

vendor: google.golang.org/grpc v1.56.3

server: prohibit more than MaxConcurrentStreams handlers from running at once
(CVE-2023-44487).

In addition to this change, applications should ensure they do not leave running
tasks behind related to the RPC before returning from method handlers, or should
enforce appropriate limits on any such work.

• grpc/grpc-go@v1.56.2...v1.56.3

[crazy-max]

Why do wee need both commits 1.56.2 and 1.56.3 and not just 1.56.3?

[thaJeztah]

I had the 1.56.2 commit because that's the version used by moby/moby currently (had it in a branch I was working on), then recalled that the latest Go CVE also affected grpc; I thought having the CVE-fix in a separate commit made it more apparent, and allowed for reviewing the security fix in isolation.

[tonistiigi]

I think these need to land in containerd first. Otherwise, we don't know what this is breaking. The CVE does not apply to buildkit afaics because buildkit can only be accessed from authenticated API.

[thaJeztah]

Related containerd PRs;

• [release/1.7] vendor: google.golang.org/grpc v1.56.3 containerd/containerd#9248
• [release/1.6] Bump grpc to v1.56.3 containerd/containerd#9285

[thaJeztah]

Update in containerd was merged; this good to go, or do we need to wait for containerd to release it? (did a quick rebase to get a fresh run of CI)

[jedevc]

Update in containerd was merged; this good to go, or do we need to wait for containerd to release it?

Do we not need to vendor containerd to the version with the fix.

[thaJeztah]

I guess the important questions here were;

• if we update this dependency, is CI still happy connecting to the current version of containerd (without it having updated GRPC); and it looks it does
• Is the containerd module happy with the updated GRPC version (and not causing havoc in the dependency tree); and the update worked in containerd's repository, and was accepted.

It's always the question who "owns" the dependency, but with go modules I don't think there's no other choice than "It's SemVer, so nobody own, and SemVer compatible means "we shouldn't care" (..... in an ideal world).

I opened this PR because I was in the process of updating the docker / moby dependency in BuildKit; for Moby we're already on this version, because the Google logging driver forced us to move to a newer version, so while Moby not yet has a go.mod, I do treat it as such, so update dependencies to versions Go modules would enforce. As there's a security fix in this version, I didn't want to "stuff" that update together with other updates; in case we must consider backporting this update (I know people already started to ask questions about BuildKit and Buildx being vulnerable because scanners started flagging them).

[thaJeztah]

@tonistiigi @crazy-max PTAL; any concerns remaining on this one?