[v4.2.0-rhel] Adjust x/text, x/tools, and x/net versions

[cevich]

Commits f34c272 and d25cb5f upgraded these modules along with
golang.org/x/crypto. PR #25624 subsequently downgraded the
crypto module but missed rolling back these other changes to
Unfortunately the newer versions of these other modules fall
between the differences from Fedora to RHEL, so CI missed
their RHEL incompatibility. Under RHEL podman fails to
compile with the error:

_build/src/github.com/containers/podman/vendor/golang.org/x/net/http2/transport.go:1109:13:
tc.NetConn undefined (type *tls.Conn has no field or method NetConn)

Rollback x/text -> v0.15.0, which then through
make vendor pulls in adjustments to x/tools and x/net. Though
the versions are still newer than what they were prior to
f34c272/d25cb5f, so as far as podman releases go, they're actually
newer than what was available previously.

Manually tested on both RHEL 9.0 & 8.6

Does this PR introduce a user-facing change?

None

[cevich]

Thanks for double-checking @dashea. @mheon @Luap99 PTAL. Some necessary slipped-through-the-cracks changes 😞 I manually tested that they build on RHEL. Probably should have done that with my other PR 😞

[TomSweeneyRedHat]

@cevich seeing downgrades in Libraries like this makes me nervous. Are you able to run https://pkg.go.dev/golang.org/x/vuln/cmd/govulncheck to make sure nothing pops with these changes?

[Luap99]

@cevich @TomSweeneyRedHat we need to compare against the base of f34c272 as this was the first commit which bumped these things.

So in total all these x versions still receive several updates as such I think saying downgrade is wrong, since none of the bump to far versions build in RHEL it means we never included the newer libs in the package and as such even after this we still should only get upgrades.

Overall sure it might be that there are other CVE's fixed in these versions so it is good to double check that but AFAIK if they were not reported before then we should have no CVE of concerns in them.

[cevich]

Correct, "downgrade" is maybe not the best word. It makes sense prior to this commit, but not as of a few commits ago. Let me see if I can come up with a better message.

[cevich]

I attempted to install/run govulncheck but I don't think this branch's golang (1.17) is supported.

[root@a89a76b3867e podman]# $GOPATH/bin/govulncheck ./...
govulncheck: loading packages: err: exit status 1: stderr: go: errors parsing go.mod:
/var/tmp/go/src/github.com/containers/podman/go.mod:6: invalid go version '1.23.0': must match format 1.23

[Luap99]

I attempted to install/run govulncheck but I don't think this branch's golang (1.17) is supported.

[root@a89a76b3867e podman]# $GOPATH/bin/govulncheck ./...
govulncheck: loading packages: err: exit status 1: stderr: go: errors parsing go.mod:
/var/tmp/go/src/github.com/containers/podman/go.mod:6: invalid go version '1.23.0': must match format 1.23

That is not what I see, go 1.23.0 should only be set on main and not on this branch so I am not sure why this error would say 1.23.0 if you are on the branch?

I had to only run on ./cmd/podman so it didn't pick up ginkgo which it complained about. The list is quite long as it seems to report our own podman/buildah/common CVE's which I assume are backported one way or another already or weren't important enough to be backported. And some are false positives as we don't use/call the code of the CVE.

These are the only two golang.org/x vulnerabilities reported there.

Vulnerability #7: 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:
...

Vulnerability #13: GO-2023-1571
    Denial of service via crafted HTTP/2 stream in net/http and golang.org/x/net
  More info: https://pkg.go.dev/vuln/GO-2023-1571
  Module: golang.org/x/net
    Found in: golang.org/x/[email protected]
    Fixed in: golang.org/x/[email protected]
    Example traces found:
...

Either way both would already be in there before we started patching this so I doubt it matters.

[cevich]

Oh woops, I was indeed running it on the wrong branch. I had to swap to a modern CI container to install/build govulncheck then forgot to swap back to this PR's branch 😊 When I run $GOPATH/bin/govulncheck -mode=binary bin/podman now, I get a list of 53 entries. I assume that's Paul's definition of "long" ☺️ I wished govulncheck showed CVE numbers 😞

Regardless, I trust Paul's analysis and concur, there have been more than a handful we've discarded due to non-applicability (e.x. buildah/podman not using the affected function) or as not severe enough to warrant attention.

[cevich]

Are there any other concerns here? This PR is currently blocking my packaging work for two RHEL releases.

[mheon]

LGTM

[Luap99]

/lgtm

[openshift-ci]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: cevich, Luap99

The full list of commands accepted by this bot can be found here.

The pull request process is described here

Needs approval from an approver in each of these files:

• OWNERS [Luap99]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment

[cevich]

Thanks guys for the oversight, review, and help on this. I appreciate it.