-
Notifications
You must be signed in to change notification settings - Fork 2.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[v4.4.1-crio] Bump ocicrypt and go-jose CVE-2024-28180 #22339
[v4.4.1-crio] Bump ocicrypt and go-jose CVE-2024-28180 #22339
Conversation
[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
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
@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. |
935e893
to
23998bb
Compare
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? |
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
DO NOT MERGE this. I added a do nothing printf to force the CI to run so I can see definitively which tests are not happy. Once it's complete and the test show which aren't happy, I'll create a new commit to turn off those tests in containers#22339 [NO NEW TESTS NEEDED] Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
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 Also tailors the .cirrus.yml to turn off a number of tests. Signed-off-by: tomsweeneyredhat <tsweeney@redhat.com>
23998bb
to
05d0889
Compare
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 |
6071a2b
into
containers:v4.4.1-crio
@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. |
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?