bump golang.org/x/net to v0.8.0

[lsm5]

Resolves: CVE-2022-41723
Ref: https://cve.mitre.org/cgi-bin/cvename.cgi?name=2022-41723

btw, does renovate catch indirect dependencies?

[lsm5]

/packit copr-build

[lsm5]

ignore the epel9 failure. centos-stream-9 builds are passing so that's good enough. epel9 was enabled on the copr for packit gating tests for container-selinux, it's of no concern here atm.

[mtrmac]

Thanks!

[mtrmac]

btw, does renovate catch indirect dependencies?

It seems it can be configured to. I’d prefer not to take that hassle, there are many more indirect dependencies than direct dependencies, so that would be more interruptions.

So, is this a situation of the current process working just fine, or is this a fire drill that should have been prevented by updating the indirect dependencies (and noticing the vulnerability report and proactively doing something about it)?

(For the record, it seems to me that the only possibly affected feature is something deep in OCI encryption; most other code uses HTTP/2 via the implementation in the standard library instead.)

[lsm5]

It seems it can be configured to. I’d prefer not to take that hassle, there are many more indirect dependencies than direct dependencies, so that would be more interruptions.

Ack, fair enough.

So, is this a situation of the current process working just fine, or is this a fire drill that should have been prevented by updating the indirect dependencies (and noticing the vulnerability report and proactively doing something about it)?

Looks like the CVE was disclosed publicly only yesterday, at least going by Fedora bugs. So, there's nothing anyone could have done about it from what I can tell.

As a middle ground, I think it would still be nice for renovate to notify / create update PRs for indirect dependencies in case of CVEs and skip regular update cases, if it has such a CVE checker feature at all. Otherwise not worth the hassle. cc @cevich

(For the record, it seems to me that the only possibly affected feature is something deep in OCI encryption; most other code uses HTTP/2 via the implementation in the standard library instead.)

Ack, thanks! So, should be safe to call it a low-sev CVE RE: skopeo then? I can downgrade the fedora bz severity in that case. @mtrmac could you please cut a new release whenever you find the time? Alternatively, if you feel it's inconsequential enough, I can CLOSED DEFERRED the fedora bz. Thanks a lot!

[cevich]

create update PRs for indirect dependencies

There's an open RFE for this: renovatebot/renovate#12999

I subscribed to that, and will turn it on once it's implemented.

[mtrmac]

It seems it can be configured to. I’d prefer not to take that hassle, there are many more indirect dependencies than direct dependencies, so that would be more interruptions.

Ack, fair enough.

(To maybe clarify, if it’s work that needs doing, by all means let’s do it. I’d just like not to add to the project overhead unnecessarily.)

---

(For the record, it seems to me that the only possibly affected feature is something deep in OCI encryption; most other code uses HTTP/2 via the implementation in the standard library instead.)

Ack, thanks! So, should be safe to call it a low-sev CVE RE: skopeo then? I can downgrade the fedora bz severity in that case.

I’m to familiar with the OCI encryption’s use of GRPC, so I’m not sure. I think it’s safe to say that it’s likely to affect a very small percentage of users, and IIRC it’s “only” a DoS anyway…

---

@mtrmac could you please cut a new release whenever you find the time?

@lsm5 Sure; just on the main branch, or are some backports necessary?

[lsm5]

@mtrmac sorry i missed your ping. The latest on fedora is v1.11 which I guess was cut from release-1.11 ? So, unless you're ready to cut a new minor version, I'd say only release-1.11. I can cherrypick the commit over there if need be.

[lsm5]

We might need backports for RHEL as well.

@TomSweeneyRedHat @jnovy could you please let us know what skopeo releases are active on RHEL ?

[jnovy]

These are upstream maintenance branches for skopeo which are still under support in RHEL @lsm5

release-1.6
release-1.11

[lsm5]

/cherry-pick release-1.11

[lsm5]

isn't openshift bot enabled here? I can do manual backports.

[lsm5]

release-1.11: #1948

building release-1.6 on Fedora 38 gives me some build errors because of an older golang:

$ make
CGO_CFLAGS="" CGO_LDFLAGS="-L/usr/lib64 -lgpgme" GO111MODULE=on go build -mod=vendor "-buildmode=pie" -ldflags '-X main.gitCommit=2b16a1ccfb89ef07688d191ed97712622e2aa7e0 ' -gcflags "" -tags "   " -o bin/skopeo ./cmd/skopeo
# golang.org/x/sys/unix
vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_linux.go:2271:9: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/syscall_unix.go:118:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
vendor/golang.org/x/sys/unix/sysvshm_unix.go:33:7: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)
make: *** [Makefile:140: bin/skopeo] Error 1

@jnovy what RHEL versions need release-1.6 ? Both 8 and 9? Just wanna make sure it builds before submitting PR.

[jnovy]

4.0 stable stream requires release-1.6 @lsm5

[mtrmac]

$ make
vendor/golang.org/x/sys/unix/syscall.go:83:16: unsafe.Slice requires go1.17 or later (-lang was set to go1.16; check go.mod)

Assuming the compiler is new enough (is it?), go mod tidy -go=1.17 && make vendor might help. (It might require another go mod tidy … && go mod tidy … run; if so, the command will ask for that.)

[mtrmac]

We might need backports for RHEL as well.

OK, given that, let’s backport to 1.11 and release a 1.11.2 from that branch, instead of making a 1.12 release from main and a 1.11.2 just for RHEL.

[lsm5]

release-1.6 #1949

[mtrmac]

New version release PRs: #1951 #1952 . (If you tag a new release, be careful to tag it at the commit with the right version.go content.)