Begin forwarded message:

> From: Jeff Johnson <n3npq@mac.com>
> Date: July 17, 2008 12:17:58 PM EDT
> To: Dave Shield <D.T.Shield@liverpool.ac.uk>
> Subject: Re: Unsnarling an rpmdb from the HR MIB
>
>
> On Jul 17, 2008, at 11:51 AM, Dave Shield wrote:
>
>> 2008/7/17 Jeff Johnson <n3npq@mac.com>:
>>> I still suggest eliminating -lrpm entirely.
>>
>> That's clearly a desirable long-term goal.
>> But I suspect it's going to take more than a little while to
>> achieve this.   We tend to be reluctant to make drastic
>> changes to the code for a released branch, so this work
>> is probably really looking at 5.5 and above.
>>
>
> Yes. But 0b files in some directory is easily retrofitted
> with either a timer on script execution (the script is trivial),
> or even by a cron script.
>
> The patching in rpm is not hard at all either. Alas, I cannot
> control what @redhat.com and @rpm.org decide to do, but I
> certainly can apply pressure through other means, including
> signing up SElinux types, to club the patch into all versions of
> rpm (with a periodic, say once every hour, cron job script running
> for those who simply cannot upgrade rpm but can upgrade net-snmp).
>
>> One consequence of this is that it's probably worth
>> looking at applying the rpm-5 patched for -lrpm
>> linkage to the current branches.
>>    How hairy are these patches likely to be?
>> Or put another way, how long would it take you to
>> construct a suitable AutoFu invocation?   :-)
>>
>
> The AutoFu will be nasty, but is doable.
>
> The underlying issue that I waited for a _MAJOR_ release of
> rpm in order to implement, is that the malloc rules have changed.
>
> The rule in rpm-5.0 is
>      All data retrieved from a Header MUST be free'd.
> rather than the API Baroqueness of
>     Some data must not be free'd.
> that rpm has always had.
>
> See headerFreeData() for where the Baroque'ness is hidden.
>
> Changing malloc rules for retrieved data is best dealt with in  
> applications,
> not through legacy retorfits, or additional flags, or wrappers or  
> any other
> pretense that the rules have not changed when, in fact, the rules  
> have changed.
>
> rpm-4.6 has decided to hedge their bets with -D_COMPAT_4_4 flag,  
> but is also
> clearly on a path to
>      All data from a Header MUST be free'd (if you access with opt- 
> in flag).
> I've chosen a major release path instead, and carry a rpm4compat.h  
> set of wrappers
> retrofit in rpm-5.0 instead.
>
> Note that the rpm-5.x "compatibility" through
>     #include <rpm4compat.h>
> is not a viable option for net-snmp, the wrappers in rpm4compat.h  
> have memory leaks,
> and I strongly believe that applications, not rpm, are the best  
> place to fix a change in malloc rules.
>
> But also note that the patching for net-snmp to free all, not just  
> some, memory
> when using rpm-5.0 is quite easy to do as well. I just wanted to  
> warn you before you
> attempted using the compatibility layer in rpm-5.0.
>
>>
>>
>>
>> One other thing to check - re-reading your earlier message,
>> I get the impression that the /var/cache/hrmib data will
>> be populated automatically by "new" RPM installations.
>>     Is this correct?
>>
>
> Yes. Every addition/deletion to an rpmdb is synchronously coupled to
> an addition/deletion in /var/cache/hrmib. You will get exactly the  
> same answer
> whether you traverse /var/cache/hrmib or iterate on /var/lib/rpm,  
> modulo
> a rather teensy time window that will self correct on next traverse.
>
> There is zero loss of functionality for HR MIB if /var/cache/hrmib  
> is used instead
> of /var/lib/rpm/Packages.
>
> You can quibble about time windows, and data consistency, etc etc  
> in the HR MIB
> data, but linking -lrpm certainly has far worse DoS flaws because  
> of stale
> POSIX mutexes than what I have implemented in /var/cache/hrmib.
>
> If necessary, I can add a fcntl lock mechanism, but I hardly think  
> that the HR MIB
> return values have clearly defined semantics when an rpm upgrade is  
> concurrently
> running while net-snmp is populating a HR MIB reply.
>
>> (My initial assumption is that this cache would have to
>> be built manually, using some form of cron job.  But I
>> now suspect that's not the case.  Can you please confirm?)
>>
>
> There's a one-time cost to initially populate /var/cache/hrmib,  
> yes. But in
> a "library push" model, that becomes an rpm, not a net-snmp, problem.
>
> Convinced yet? If more is needed, or we have to do the change more  
> slowly,
> I can do that too. But I do think -lrpm was a very bad  
> architectural mistake on
> my part. Who knew in 1998?
>
> 73 de Jeff