And, a savvy guess at the forensics that might explain why
1) this flaw/patch is Mandriva peculier
2) Mandriva uses hdlist
is that the hdlist construction was b00gered up at some
point in the past. Certainly there is no pathway through
rpmbuild -> rpmfiNew() -> rpmtsRun() that results in
fi->posttransprog == NULL, which is all the patch checks for.
But the header returned from the callback == random application bubble
gum scraped from the bottom of the application's chair from a rpmlib
That is the "core problem" with modified (by genhdlist or other unknown
processes that create header-like objects) that are passed into rpmlib
without sufficient distro/repo QA on the binary format markup contained
And the bleeping (*callback) is a fundamental design flaw in rpm code,
one cannot pass complicated blobs around with no sanity checks unless
one has an adequate understanding of what QA means.
73 de Jeff crossing the buggy RPM vendor streams, lookout!
On Dec 6, 2008, at 1:13 PM, Jeff Johnson wrote:
> I should be careful when throwing acid around ...
> Like many rpm flaws, the fix is usually in a very different
> place then where the symptom is seen.
> In this case, the underlying flaw is an unpopulated
> That needs to be prevented in rpmbuild, not "best effort" skipped in
> That is my definition for "right" because there are most certainly
> missing data failure symptoms if RPMTAG_POSTTRANSPROG has gone AWOL,
> not only in rpmtsRun().
> 73 de Jeff
Received on Sat Dec 6 19:29:46 2008
- application/pkcs7-signature attachment: smime.p7s