+++ This bug was initially created as a clone of Bug #1613061 +++ While assessing a problem where Containers were constantly requiring updates due to frequent released kernel CVEs, it was determined that the source of such required updates was the fact that some development-oriented containers required the install of kernel-headers sub-RPM that also gets rebuilt for CVEs even though most of the time its content doesn't change. In order to avoid the aforementioned container churn we'll start to provide a pre-calculated hash for the content shipped within kernel-headers sub-RPM which can easily be consumed by Container tooling to determine if relevant content was updated for new releases and only proceed with Container re-builds if that's really necessary. From redhat-rpm-config, we need an update to the fileattrs and scripts library directories so these exported content hashes can be grabbed at RPM-build time and exported as Provides: dynamically (similarly to what's done for the symbols checksums via fileattrs/kabi.attr and kabi.sh) --- Additional comment from Red Hat Bugzilla Rules Engine on 2018-08-06 18:16:40 EDT --- Since this bug report was entered in Red Hat Bugzilla, the release flag has been set to ? to ensure that it is properly evaluated for this release. --- Additional comment from Rafael Aquini on 2018-08-06 18:28 EDT --- Proposed changeset to accomplish the requested feature. Tested as follows: Here are the tests results, done with RHEL-7.5 base kernel 862.el7, comparing against builds 863.el7 (no header changes) and 864.el7 (header changes): $ for r in kernel-headers*.rpm; do rpm -qp --provides $r; done glibc-kernheaders = 3.0-46 kernel-headers = 3.10.0-862.el7.1 kernel-headers(x86-64) = 3.10.0-862.el7.1 kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d glibc-kernheaders = 3.0-46 kernel-headers = 3.10.0-862.el7.2 kernel-headers(x86-64) = 3.10.0-862.el7.2 kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d glibc-kernheaders = 3.0-46 kernel-headers = 3.10.0-863.el7 kernel-headers(x86-64) = 3.10.0-863.el7 kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d glibc-kernheaders = 3.0-46 kernel-headers = 3.10.0-864.el7 kernel-headers(x86-64) = 3.10.0-864.el7 kernel-headers-checksum = 33a0e9526e77d947bd631c41e5ec201861ec672b NOTE: build 3.10.0-862.el7.1 was done before applying the kernel.spec changes and build 3.10.0-862.el7.2 after applying the .spec changes, as noted on the following debug output: Processing files: kernel-headers-3.10.0-862.el7.1.x86_64 ++ awk '/KERNEL_HEADERS_CHECKSUM/ {print $3}' /home/remote/raquini/rpmbuild/BUILDROOT/kernel-3.10.0-862.el7.1.x86_64/usr/include/linux/version.h ++ sed -s 's|\"||g' + checksum= + '[' -z '' ']' ++ find /home/remote/raquini/rpmbuild/BUILDROOT/kernel-3.10.0-862.el7.1.x86_64/usr/include -type f -name '*.h' '!' -path /home/remote/raquini/rpmbuild/BUILDROOT/kernel-3.10.0-862.el7.1.x86_64/usr/include/linux/version.h -exec cat '{}' ';' ++ sha1sum - ++ cut -f 1 -d ' ' + checksum=43ce681a4082c2c1051f37caaf9f4949ac82a66d + echo 'kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d' Provides: glibc-kernheaders = 3.0-46 kernel-headers = 3.10.0-862.el7.1 kernel-headers(x86-64) = 3.10.0-862.el7.1 kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d Processing files: kernel-headers-3.10.0-862.el7.2.x86_64 ++ awk '/KERNEL_HEADERS_CHECKSUM/ {print $3}' /home/remote/raquini/rpmbuild/BUILDROOT/kernel-3.10.0-862.el7.2.x86_64/usr/include/linux/version.h ++ sed -s 's|\"||g' + checksum=43ce681a4082c2c1051f37caaf9f4949ac82a66d + '[' -z 43ce681a4082c2c1051f37caaf9f4949ac82a66d ']' + echo 'kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d' Provides: glibc-kernheaders = 3.0-46 kernel-headers = 3.10.0-862.el7.2 kernel-headers(x86-64) = 3.10.0-862.el7.2 kernel-headers-checksum = 43ce681a4082c2c1051f37caaf9f4949ac82a66d One curiosity on the kernel-headers-checksum.sh patch: we need to keep the conditional checksum calc as placed as the dynamic provides finding mechanism would toss out an RPM error on cases where version.h does not export KERNEL_HEADERS_CHECKSUM -- I can anticipate this happening when building out of old branches that do not have the spec changes on build-hosts that do have the rpmlib bits updated. So that conditional case will kick in and we'll have a hash calculated as proposed before (only blacklisting version.h itself) to avoid the following RPM error due to empty kernel-headers-checksum provides, on build: rpm error: invalid dependency (bad format): kernel-headers-checksum =
Seems like NOTABUG.
Well it's not a bug but an RFE, the problem is that the description is private. Which is not at all appropriate for a Fedora RFE. Rafael, please open it up. It also doesn't help that the see-also bug is completely inaccessible.
Created attachment 1473980 [details] Proposed changeset to be included downstream (RHEL) v2
(In reply to Panu Matilainen from comment #2) > Well it's not a bug but an RFE, the problem is that the description is > private. Which is not at all appropriate for a Fedora RFE. Rafael, please > open it up. > > It also doesn't help that the see-also bug is completely inaccessible. RH BZs are closed by default, when I cloned this one BZ did it that way (private description) and I completely forgot to change it -- I'm sorry. -- Rafael
Created attachment 1474007 [details] Proposed changeset to be included downstream (RHEL) v3 Carlos O'Donell also pointed out that deterministic sorts can only be achieved with LC_ALL=C locale, thus we're forcing LC_ALL=C for the sub-shell running the hashing routine.
This bug appears to have been reported against 'rawhide' during the Fedora 29 development cycle. Changing version to '29'.
This message is a reminder that Fedora 29 is nearing its end of life. Fedora will stop maintaining and issuing updates for Fedora 29 on 2019-11-26. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as EOL if it remains open with a Fedora 'version' of '29'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 29 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.