glibc-2.42-6.fc43.src.rpm and glibc-2.42-7.fc43.src.rpm have several files with duplicate build-ids. This is a problem in fedora because, since -7 was not submitted as an update, it was not signed. This means the -7 RPMs don't carry the RPM/IMA signatures that released RPMs do. But since they have some duplicate build-ids, debuginfod.fedoraproject.org happens to prefer the wrong one (e.g., 57f6900d44d37352280570abdffc4f01a1803226), which causes ima:enforcing errors in debuginfod operations. The root cause appears to be that glibc's wrap-find-debuginfo.sh script, which is related to debugedit/rpm's find-debuginfo.sh, fails to pass debugedit's --build-id-seed=SEED parameter, as normally done from other rpms. This makes the hashes purely content-based, and thus duplicate when barely anything changes between src.rpm revisions. Please consider adding a --build-id-seed=SEED parameter to the $debugedit invocation in your wrapper. If you don't have the rpm n-v-r-a handy (which is what normal rpmbuild uses), you could even just pass some random hex-dump gunk from /dev/urandom. Reproducible: Always
Isn't this basically saying that the builds are too reproducible? We copy back libc.so.6 as it was before running find-debuginfo.sh, so that we can add a special .symtab for valgrind. See bug 1965374. This undoes any build-id change that find-debuginfo.sh may have made, breaking debuginfo linking if find-debuginfo.sh recomputes the build ID. I'm open to other suggestions for fixing this. On the other hand, the debuginfod behavior seems problematic because it seems to allow Fedora packages to deny debuginfo availability for unrelated packages.
(In reply to Florian Weimer from comment #1) > Isn't this basically saying that the builds are too reproducible? You can still have completely reproducible builds by salting buildids with the n-v-r-a. > We copy back libc.so.6 as it was before running find-debuginfo.sh, so that > we can add a special .symtab for valgrind. See bug 1965374. This undoes any > build-id change that find-debuginfo.sh may have made, breaking debuginfo > linking if find-debuginfo.sh recomputes the build ID. OK, I only partly understand all this, but it appears as though your wrapper-generated libc.so's ALL end up with unsalted, gcc/ld-generated original buildids, rather than those recomputed by the wrapped debugedit/find-debuginfo.sh. Perhaps the wrapper could overwrite the buildid early on in its lib* saving/restoring process. (Wishful thinking, but these days, the ld --package-metadata=JSON field provides a perfect source of salt, but don't think ld consumes it that way. cc: nickc) > On the other hand, the debuginfod behavior seems problematic because it > seems to allow Fedora packages to deny debuginfo availability for unrelated > packages. That's true, there is a vulnerability to actively hostile packages, and to the occasional process mishap like this, but statistically not toward accident.
(In reply to Frank Ch. Eigler from comment #2) > (Wishful thinking, but these days, the ld --package-metadata=JSON field > provides a perfect source of salt, but don't think ld consumes it that way. > cc: nickc) We currently do not have package notes (bug 2362272). If the linker includes allocated PT_NOTE segments in its build-id computation, generating the package notes, would fix this issue here, as well, right?
I am not completely sure what is going on here and why it is an issue. In theory build-ids are globally unique unless they are essentially the same build. build-id clashes normally only occur when a binary is copied. Being the same build shouldn't really be an issue since packages are build in a build directory containing their name and version (which will go into the debuginfo as paths and so create different hashes between packages and versions). The one thing not normally included is the release (the r in nvra). Different architectures obviously generate different build-ids. I assume what is happening here is the release number isn't hashed into the binary, so the same package-version-r1 and package-version-r2 build get the same build-id (assuming the build environment is exactly the same). Which should in theory not really be an issue because it just means the binary doesn't technically need to be upgraded between releases. But no two binaries with the same build-id will ever be installed at the same time. I am not sure why that would be an issue for ima signatures, since they are the same binary bit-for-bit the ima signature should be exactly the same. For debuginfod it might indeed be unclear which "release" version if the debuginfo (or sources) to provide for such a build-id, but it really shouldn't matter. Either release debuginfo or sources should match the binary. If you do want to make sure the build-id between releases of the same package-source always have different build-ids you can indeed use debugedit to update the build-id using --build-id --build-id-seed=%{VERSION}-%{RELEASE}. (Please don't use /dev/urandom which would make the package not-reproducible.)
I looked for a bit at the build-id computation in BFD ld, and I think the package notes added here https://src.fedoraproject.org/rpms/glibc/pull-request/148 should be covered by the hash. So I don't think we'll need separate seeding because the notes already contain a version-release string.
> I am not sure why that would be an issue for ima signatures, since they are > the same binary bit-for-bit the ima signature should be exactly the same. The problem is that one of the koji builds was never submitted to bodhi as an testing/stable-bound build. Therefore it never got signed, lacking IMA signatures. Thus the latter were rejected when a debuginfod client happened to receive them under the (now default) ima:enforcing policy. There are a couple of OTHER links in the causality chain where this could have been prevented, but this is one of the earliest.