[Rpm-maint] [PATCH 3/4] Add sepdebugcrcfix to fixup old style gnu_debuglink CRC checksum.

Thierry Vignaud thierry.vignaud at gmail.com
Mon Jun 13 12:33:24 UTC 2016

On 7 June 2016 at 11:50, Mark Wielaard <mjw at redhat.com> wrote:
>> > Some old tools might still use the .gnu_debuglink section to find
>> > separate debuginfo files instead of build-id style lookups. When
>> > dwz has compresses the .debug files the original CRC in the main
>> > ELF file will no longer match. Make sure to run sepdebugcrcfix
>> > after dwz to recalculate the CRC.
>> >
>> > The original fix was created by Jan Kratochvil based on code
>> > from GNU binutils BFD. https://bugzilla.redhat.com/show_bug.cgi?id=971119
>> > I added a testcase to make sure the CRCs were all correctly
>> > updated after dwz has run to compress a debuginfo package.
>> WARNING: Note that the original Fedora patch has issues!
>> Panu (the then upstream rpm.org maintainer) said it should _not_ be
>> upstreamed when we bring the issue up:
>> Once we applied this patch to rpm-4.12 in Mageia, rpm silently dropped
>> the suid/sgid bits from files if they were re not explicitely listed with %attr
>> This was breaking packages...
>> See https://bugs.mageia.org/show_bug.cgi?id=14691
> Could you provide a small example? From the bug report it isn't clear if
> it really is a bug with that particular fix or that it is caused by bad
> usage of attributes. If we have a small example we can create a test
> case for it.

Here's one example attached.
With current FC patch applied to rpm (aka uncommenting the patch at

With "%define debug_package %{nil}", "ll /bin/test2" shows:
-rwsr-xr-x 1 root root 6128 Eve  13 13:56 /bin/test2*
With "#define debug_package %{nil}", "ll /bin/test2" shows:
-rwxr-xr-x 1 root root 7184 Eve  13 13:55 /bin/test2*

When the rpm patch is not applied, both cases works OK (aka ls -[ol]
reports the suid bit)

>> Panu answered:
>> ====================== BEGIN
>> As for the "are you sure we (still) need this patch" question, the
>> answer has always been "almost certainly not".
>> The short summary is that the issue it fixes only is present if you
>> use dwz to compress the debuginfo (like Fedora does), and even then
>> case it only affects a handful of toolchain developers in the entire
>> world.
>> See https://bugzilla.redhat.com/show_bug.cgi?id=971119 for further
>> explanation of the issue, comment #9 answers the who is affected part.
>> Personally my opinion is "just kick out the stupid patch already" :)
>> but judge for yourselves.
>> ====================== END
> I am missing some context here. But it reads like if you don't use dwz
> support then it doesn't fix any real issue. So, then you can drop that
> patch also. Which is true.
> But you do seem to use compressed debuginfo packages. In which case it
> does fix a real issue. The issue is that if you create .debug files
> with .gnu_debuglink support then you need to make sure that the CRC is
> calculated correctly.  I included a testcase to show what that issue is
> (the testcase will fail without the patch applied).

According to Panu, "t only affects a handful of toolchain developers
in the entire world" whereas it does break havoc here...

> Also note that one of the goals of improving and cleaning up debuginfo
> packages is so more people can easily use them, in which case it will
> impact more than just a few hackers that manage to get them properly
> installed.

I don't argue against that :-)
I'm just stating that the FC patch breaks suid here...
If suid bit is explicitely listed as %attr(...), it works as rpm enforces it.
But if it has been set by install/chmod/... then it's lost when
generating debuginfo with that patch

I would like for this to be fixed before the patch is merged :-)
You can add the attached test.spec to the testsuite
-------------- next part --------------
A non-text attachment was scrubbed...
Name: test.spec
Type: text/x-rpm-spec
Size: 537 bytes
Desc: not available
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20160613/c3487510/attachment.bin>

More information about the Rpm-maint mailing list