Comment 4 for bug 910708

As Per Oyvind has seen, the problem disappears when the
the actual header being retrieved from the database
is reinstalled. So the root cause is something other
than the segfault manifestation.

segfaults are the easiest thing in the world to repair *IF*
one has a reproducer.

I cannot reproduce the process by which the bad data
ends up in an rpmdb (but do not have x86_64 or virtual box
VM's which were part of either this or similar reports).

The code paths involved with signature verification are
quite well tested (details if necessary, see http://hw.jbj.org:8010
waterfalls), and I'm fairly confident that any implementation flaw
will be fixed as MANDATORY signature (if accepted) is deployed.

Meanwhile, its also quite simple to just rip out the code that
attempts to verify binding signatures on pub keys needed
to verify package header signatures during rpm --verify.
The functionality there is dependent on what threat model
one has wrto software distributed through *.rpm packages,
and YMMV, everyone's does.

But agreed "distressing" because of the artificially enhanced "security"
priority as well as the obvious flaw of segfaulting (though the root cause
isn't the segfault per se, but rather bad data being returned from an
rpmdb triggering a segfault, where the data was added through unknown
and likely buggy code paths).