[Rpm-maint] whither rpmbuild, whither rpm?

Panu Matilainen pmatilai at redhat.com
Wed Apr 16 06:56:39 UTC 2008

On Tue, 15 Apr 2008, R P Herrold wrote:

> A quote from a post earlier to day piqued by interest:
>> The ldconfig hackery in rpm is going away sooner or later, what I want to 
>> see is some more generic mechanism for packages to queue actions to happen 
>> at end of the transaction. ...
>>   ...
>> Several ways to accomplish that, I've just been too busy whacking potential 
>> buffer overflows and similar fun to have a chance to really think about it 
>> :)
> So write the limited %pre and %post grammar and float a candidate; without a 
> constrained grammar, it is just tossing a pail of water into the wind; in the 
> absence of limits or defined ways to perform permitted operations, continued 
> deference to a nice Turing complete shell interpreter's bag of tools doomed 
> transactional rollbacks, and makes avoidance of 'potential' buffer overflows 
> the least of one's worries;  an obfuscated 'ulink' of two in a %pre or %post, 
> or dropped in as an 'at' script for time delay action, has much higher in the 
> realm of damage potential.

No I don't have a specification for it, I described the kind of thing 
I have in mind in hopes of getting some constructive ideas (or even 
patches) from the list. I didn't say it would mean a limited %pre/%post 
grammar, it wont.

> It seemed to me that chasing 'potential' buffer overflows, on code that 
> valgrind is largely happy with;  I watch all rpm related filings and have for 
> many years, and frankly, this asserted concern with code cleanup in the name 
> of avoiding insecure! buffer! overflows! just looks like makework to me.

Valgrind being happy doesn't mean that much, it's pretty clueless as to 
what happens on the stack which is where the worst offenders in rpm are.

If auditing for potential buffer overflows, stack overruns and the like in 
a code that spends most of it's time running as root seems like makework 
to you then frankly, that's *your* problem.

> So being interested in the future or RPM and RPMBUILD, I figured, why not go 
> to the source, and look at the rpm.org website, as 'We're relaunching 
> rpm.org, with a new direction for future development of RPM. RPM should not 
> be the province of one company, or a small set of developers' -- edit by: 
> 2007-10-15 10:03:03 by PanuMatilainen
> -- http://wiki.rpm.org/FrontPage
> from: http://wiki.rpm.org/News
> RPM development switches to GIT (Mar 31th 2008)
>    *      Rpm code repository has been converted from Mercurial to GIT, 
> effective immediately. Access details are documented on GetSource page.
> from: http://wiki.rpm.org/Docs/RpmOrgFAQ
> So what, specifically, are you doing with RPM? And where is the work going to 
> happen?
> We have set up a new [WWW] repository, [link to: http://hg.rpm.org/]

Right, a stale link, thanks for pointing that out.

> from: http://wiki.rpm.org/Docs/RpmOrgFAQ
> When is all of this happening?
> Starting now. Planning and review happening over the next 3-6 months -- edit 
> 2006-12-15 23:20:06 by JamesBowes
> hmmm  ...
> from:  http://wiki.rpm.org/Roadmap
> Build process cleanup
>    *      Clean up, modernize and correct RPM's auto*tool usage
>    *      Make compilation free of warnings
> Let's look elsewhere:
> from: https://bugzilla.redhat.com/show_bug.cgi?id=441808
> by: Panu Matilainen
> Sure there's an API of sorts for this in librpmbuild (even if it's not 
> exactly very sane or friendly to use), ...
> NOTABUG in the sense that couple of ways to access this data do exist. There 
> are plans to provide a saner API for the build parts for rpm (including 
> python bindings), but that's way way out of scope for RHEL 5.
> ===================================================
> well ... Where ARE the asserted 'plans to provide a saner API for the build 
> parts for rpm (including python bindings)' What else is slated to be 
cut out 
> of RPM as 'Remove ancient, deprecated APIs'?
> I sure don't see them in a form suseptible to implementation or comment 
> anywhere at http://www.rpm.org/ -- all I see is these days is one developer 
> from one company with a non-visible plan on this tine of the fork.

You managed to find the roadmap already, how's that non-visible? You 
also found the FAQ which says

Give RPM a full technical review, based off of RPM 4.4.2. This is the 
common base for Novell and Red Hat. Look what vendors have on top of 4.4.2 
and work towards a shared base. Figure out which pieces or code paths are 
unnecessary, poorly implemented, or receive little to no use, and either 
clean them up or clear them out. Make RPM simpler.

This is precisely what we've been doing and will be for some time still.
"There are plans to improve <foo>" is just one way of saying "we're 
planning to look at and improve <foo> when the time comes".

 	- Panu -

More information about the Rpm-maint mailing list