[release/1.7]: api: update github.com/containerd/ttrpc v1.2.5 to align with containerd 1.7 module

[thaJeztah]

• depends on / stacked on [release/1.7 backport] vendor: github.com/containerd/ttrpc v1.2.5 #10373
• follow up to [release/1.7] Add API go module #10189 (comment)

[release/1.7] api: update github.com/containerd/ttrpc v1.2.5

Update the dependency and the indirect golang.org/x/net version to align
with containerd 1.7 itself, and to prevent a vulnerability being detected.

This should not generally be an issue, as the API module is used by
containerd 1.7 and up, which already depend on a more current version of
these dependencies.

Before this:

govulncheck ./...
Scanning your code and 251 packages across 13 dependent modules for known vulnerabilities...

=== Symbol Results ===

Vulnerability #1: GO-2024-2687
    HTTP/2 CONTINUATION flood in net/http
  More info: https://pkg.go.dev/vuln/GO-2024-2687
  Module: golang.org/x/net
    Found in: golang.org/x/[email protected]
    Fixed in: golang.org/x/[email protected]
    Example traces found:
      #1: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.ConnectionError.Error
      #2: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.ErrCode.String
      #3: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.FrameHeader.String
      #4: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.FrameType.String
      #5: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.Setting.String
      #6: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.SettingID.String
      #7: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.StreamError.Error
      #8: services/version/v1/version_grpc.pb.go:13:2: version.init calls status.init, which eventually calls http2.chunkWriter.Write
      #9: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.connError.Error
      #10: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.duplicatePseudoHeaderError.Error
      #11: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.headerFieldNameError.Error
      #12: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.headerFieldValueError.Error
      #13: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.pseudoHeaderError.Error
      #14: events/task_fieldpath.pb.go:85:20: events.TaskIO.Field calls fmt.Sprint, which eventually calls http2.writeData.String

Your code is affected by 1 vulnerability from 1 module.
This scan also found 0 vulnerabilities in packages you import and 3
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.

After this:

govulncheck ./...
Scanning your code and 251 packages across 13 dependent modules for known vulnerabilities...

=== Symbol Results ===

No vulnerabilities found.

Your code is affected by 0 vulnerabilities.
This scan also found 0 vulnerabilities in packages you import and 3
vulnerabilities in modules you require, but your code doesn't appear to call
these vulnerabilities.
Use '-show verbose' for more details.

[dmcgowan]

This bumps them ahead of what is in main, I'm fine taking these updates though

[thaJeztah]

This bumps them ahead of what is in main, I'm fine taking these updates though

Oh! In the API module in main you mean? That's a good point, I didn't check that one; I checked against the containerd "main" module in the 1.7 branch.

We should probably do the same in API 1.8.x. That one could keep a minimum version similar to the 1.7 branch (to prevent a user of 1.7 containerd with API 1.8 from being forced to update everything.

[thaJeztah]

• Opened api: update github.com/containerd/ttrpc v1.2.5 to be aligned with containerd #10366 for main (api 1.8)

[thaJeztah]

Looks like CI is happy 🥳

[thaJeztah]

@dmcgowan ptal; 🤗

[dmcgowan]

I'm -1 for bumping indirect packages through the api module. The binary packages should be responsible for that. We should get the ttrpc bump in though since that is direct and relevant.

[thaJeztah]

The point is that we won't be able to get rid of the vulnerable gopkg.in/yaml.v3 in the go.mod (dependency of logrus -> testify). I generally agree that modules should pick "lowest required version", but for packages with a vulnerability it allows bumping the version to a version we deem secure (so the minimum version we want to be used).

[dmcgowan]

so the minimum version we want to be used

If it is important to update, then we should update and tag through ttrpc since that is the direct dependency, not through the API module. I don't think that is a good reason to update indirects in a library package, the importing packages will still be able to choose their versions.

[dmcgowan]

https://github.com/containerd/ttrpc/releases/tag/v1.2.5

[thaJeztah]

I stacked this on top of #10373, so will temporarily move back to draft.

The good news; go modules was dreaming up the dependency; cleaning up the go.mod after updating made it disappear.

[thaJeztah]

Rebased after #10373 was merged; this should be ready for review 👍