 |
With the new shim version (15.8), we have taken over management of the shim package itself. The source no longer comes from Red Hat where we are having to patch out their signed data with our own. This makes it much easier to deal with it over all. Because of this, we were able to get our shim approved, signed, packaged, and pushed out quicker than other distributions. Not only this, we also have secure boot for aarch64, which our upstream (and many others) are not doing. As an aside, we've had situations where we were *ahead* of our upstream distributions in regards to shim, and patching the package to deal with that was a painful process. We did not want to do that again. This is why the shim package varies from upstream. Our shim package version, while being behind Red Hat's, doesn't mean we're vulnerable. In fact, look at RHEL's change log: * Tue Apr 16 2024 Peter Jones <pjones@redhat.com> - 15.8-4 - Bump the release to *-4* to work around a build system issue. Related: RHEL-11259 * Wed Apr 10 2024 Peter Jones <pjones@redhat.com> - 15.8-3 - Bump the release to -3 to work around a build system issue. Related: RHEL-11259 * Thu Mar 28 2024 Peter Jones <pjones@redhat.com> - 15.8-2.el8 - Fix rpm verify issue found in testing. Related: RHEL-11259 * Thu Mar 21 2024 Peter Jones <pjones@redhat.com> - 15.8-1.el8 - Update to shim-15.8 for CVE-2023-40547 Resolves: RHEL-11259 Between -2 and -4, there's nothing else happening here. Our shim is the same version of Red Hat's, which is 15.8, and they simply rebuilt their package a few times to fix "build system issues", thus the release was bumped up to compensate. Bumping our release for the sake of matching no longer makes sense to us. I understand scanners and what have you out there will treat it as a vulnerability, but that is the maintainer of those scanners problem to resolve. We encourage those vendors to reach out to us or work with us to resolve these types of issues in the future. Closing as won't fix. |
 |
I think one of the things we can do medium-long term to help with this is also break the dependency on Red Hat for the Errata, and allow ourselves to issue individual erratum as we see fit and/or need to, due to this, others, and future discrepancies. |
- Anonymous
