I've just sent this to lsb-discuss ...

Begin forwarded message:

> From: Jeff Johnson <n3npq@mac.com>
> Date: April 20, 2008 11:21:10 AM EDT
> To: lsb-discuss@lists.linux-foundation.org
> Subject: Re: LSB format packaging and security
>
> While normally I would not bring a RPM implementation flaw
>
>     https://bugzilla.redhat.com/show_bug.cgi?id=442761
>
> to an LSB discussion list, I happen to have the chore of fixing the  
> flaw this morning,
> and it illustrates the misguided reasoning within the dogged  
> insistence to
> continue "LSB format" in the LSB package "standard" forevermore.
>
> One of these bugs comes along every 6 months or so, usually from  
> "fuzzing" or
> from (as in this case) apparently from a file system failure.  
> Fixing is usually straightforward,
> but its extremely hard to design a proper engineering fix for code  
> that was written
> in 1997 and largely has not been changed in order to maintain  
> "legacy compatibility".
>
> I personally have chosen to abandon the existing *.rpm format and  
> move to
> using XAR @rpm5.org largely because (imho) the existing  
> implementation cannot
> be saved, only preserved. The level of interest in "fixing" the  
> problems in the existing "LSB format"
> or even the widely used RPMv4 format is vanishingly small, further  
> diluted by
> uninformed dpkg <-> rpm packaging wars, vendor patching, and (here  
> on lsb-discuss)
> imposed legacy compatible and "standard" constraints on acceptable  
> engineering solutions,
> as well as seta-of-the-pants benchmarking that is routinely and  
> unwisely disabling
> the digest/signature checks that are implemented in rpmlib for  
> application performance.
>
> Lemme try and illustrate what I just said to those who might have C  
> development
> expertise: Go try and fix #442761. Its a simple double free, not  
> hard. I predict that
> you will come back with an opinion of the header I/O implementation  
> identical to mine:
>      This code cannot be easily maintained and desperately needs to  
> be rewritten.
> Note that I (and others @redhat.com) had reached that conclusion  
> _BEFORE_
> LSB chose rpm for its packaging standard more than 9 years ago.
>
> And for users, lemme try a different example to clarify: if you  
> disable digest/signature
> checks reading packages, and forbid dependencies other than
>     Requires: LSB
> and mark any new functionality as an "Error:" and therefor  
> prohibited, well,
> rpm just isn't the correct choice. Running %pre/%post scriptlets  
> included in
> any (or several) archivers is a far better choice for LSB. Use what  
> "works",
> tar, cpio, deb, rpm, xar, shar, XML blobs, whatever format that is  
> useful.
>
> Any of the above archives can be made "standard" with only a modest
> amount of work. In fact RPM became a LSB standard by simply
> referencing an appendix in "Maximum RPM" and stating a defacto
> reference implementation rpm-3.0.5.
>
> (aside) Yes, the LSB format is much better documented since the  
> original
> specification, and is in fact as good as any existing documentation  
> for
> RPM format. WHich is why I encouraged Eric-Foster Johnson to include
> the LSB standard in the "RedHat RPM guide" as best available. But I  
> digress ...
>
> Most of the history is known to many LSB members. I certainly have  
> tried
> to communicate that information privately on many many occaisions.
>
> Disclaimer: The flaw is actually in retrieving  
> RPMTAG_HEADERIMMUTABLE which
> is not in "LSB format". The relevance to LSB is that there is a  
> complexity cost
> in maintaining "LSB format" everywhere for LSB (and Sun/IBM usage)  
> within RPM that cannot
> be justified 9 years later in the year 2008 imho.
>
> The flaw supplies an explicit reproducer for Russ's claim and and  
> answer to Jeff Licquia's "should be addressed":
>
> >R P Herrold wrote:
> >> My opening remark to the comment that 'We agreed at the face-
> >> to-face that RPM package version format uplift was not
> >> important and might be deferred' was -- Either uplift to RPM
> >> package version 4, or just use tarballs [ar, cpio, XML blobs,
> >> whatever];  RPM package version 3 is long obsolete,
> >> incompletely protects the content, and is subject to a known
> >> modification attack which cannot be detected in the way the v
> >> 3 signing leade is used.
>
> >That (the modification attack) sounds like something that should be
> >addressed.
>
> The flaw is also directly pertinent to Ted T'so's claim that
>     "everyone supports the RPMv3 format ... and that is indeed a  
> GOOD thing".
> as supplies an explicit reproducer for Russ's claim and Jeff  
> Licquia's "should be addressed"
>
> Note: that it is the "LSB format" not the "RPMv3 format" that is  
> under discussion here. rpm-3.0.x
> went end-of-life years ago. I have given the format to LSB as a  
> form of RPM disaster control
> because I simply have not been able to communicate the reasons why  
> the "LSB format" needs
> to be either uplifted or dropped. I have most certainly tried  
> repeatedly privately.
>
> > And the good news is that everyone supports the RPMv3 format --- and
> > that is indeed a GOOD thing!  Creating a standard which would force
> > the enterprise distro's to upgrade to RPMv5 is just not  
> interesting to
> > us.  Maybe that's what you and JBJ would like, since I'm sure you're
> > convinced of the innate superiority of the RPMv5 technology.  And
> > perhaps you're even right. But regardless, it's not clear these new
> > features that you and JBJ tout in RPM5 are useful for ISV's in the
> > general case.  (Or even the features implied by the RPMv4 package
> > format, for that matter.)
>
> My point is that "everyone supports the RPMV3 format" is a pleasant  
> lie.
>
> The "LSB format" has no integrity checks on header metadata while  
> querying or
> installing, only with a separate mode of rpm. The design goal for  
> LSB format
> packages (largely because of crypto == munition circa 1997) is the  
> fundamental
> reason.
>
> If you want to attempt an independent (of any rpm code) implementation
> in lsbinstall that can read LSB format, by all means, do that. The LSB
> code that I have looked at is (imho) in even worse shape than what is
> implemented in rpm but I am clearly biased. I assure you that I  
> would have
> swiped the code in LSB and used in rpm itself if I had thought the  
> code was
> useful.
>
> I would suggest that uplifting to RPMv4 would be useful, and I've  
> offered (and
> invited vendor maintainers) to participate. I.e. LSB would have  
> almost zero
> effort involved with "uplifting". Note that I would be perfectly  
> willing
> to write the document, and handle additions, etc. But I'm certainly  
> cognizant
> that many people are of the opinion:
>
>    I saw Jeff  Johnson wrote it and so I stopped reading.
>
> Your loss, not mine. *shrug*
>
> So far, I've heard only from Mats, basically that he has no time. No
> other person is interested in writing an "uplift" document.
>
> That all seems to be the starting point of this thread, the priority
> that should be given to writing an "uplift" document and upgrading  
> tools.
>
> All of the above should explain why I recommend publically (similar  
> to Russ)
> either uplift or drop LSB format in the LSB packaging standard.
>
> The "LSB format" either needs to be implemented from scratch or  
> abandoned.
>
> An uplift to RPMv4 will connect with the largest number of
> currently deployed RPM packages.
>
> But by all means, standardize on deb or xml blobs or anything else  
> if you wish.
>
> Just not "LSB format" any more please.
>
> Off to fix the double free, yawn ...
>
> 73 de Jeff