[v4.4.1-crio] Bump ocicrypt and go-jose CVE-2024-28180
Bump github.com/go-jose/go-jose to v3.0.0 and github.com/containers/ocicrypt to v1.1.10
Addresses: CVE-2024-28180 https://issues.redhat.com/browse/OCPBUGS-30784
Does this PR introduce a user-facing change?
None
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: TomSweeneyRedHat
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [TomSweeneyRedHat]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
@mheon do we push this through?
Let me add bloat_enabled and rerun CI, let's see if anything else passes.
@mheon, still not happy, but I think expectedly unhappy at this point.
Add the v2.6.3 go-jose fix that I had missed in the first pass.
@mheon suggestions on what's next on this?
The build test was just a flake. The other tests seem to fail consistently. I think we'll have to disable them for this branch.
@mheon so do you want me to disable the tests or can we push this through to get the CVE tended to?
I've added the changes to .cirrus.yaml from #22649 to this PR. I originally just turned off the failing System and Integeration tests that were constantly failing. After doing so, the podman machine tests were hanging. As I don't believe we need podman machine testing for this version of Podman, I turned that off, too. Holler if that should be adjusted.
Happy Green Test Buttons on this one.
A few integration tests survived; almost surprising. System tests in RHEL should validate those bits. LGTM
Why do we have both a 4.4.1-rhel and a 4.4.1-crio branch? What is the difference, seems like duplicate work to vendor the same fixes into both all the time?
/lgtm
@Luap99 Long ugly story very short, there was a particular newer version of c/storage needed by CRI-O that was not in the 4.4.1-the branch. I think there were a few other tweaks, too, but I don't recall. It was the best decision out of a couple of crappy possibilities.
@Luap99 Long ugly story very short, there was a particular newer version of c/storage needed by CRI-O that was not in the 4.4.1-the branch. I think there were a few other tweaks, too, but I don't recall. It was the best decision out of a couple of crappy possibilities.
Ack, I was sure you didn't do it without a strong reason. I just hope we try to avoid such scenarios in the future.