[lsb-discuss] LSB format packaging and security

Giovanni A. Orlando gorlando at futuretg.com
Mon Apr 21 06:35:03 PDT 2008

Jeff Johnson wrote:

Hi Everyone,

    Like I comment time ago, Linux as well LSB, need a graphical 
installer, not rpm 4.X or 5 or deb.

    While under MS Windows, it is simple, under the majestic Linux 
actually there are around +24,000 software packages include multiple 
version of the same software like Python 2.4+Python 2.5.

     So, we need a standard on this matter, and not a 'normal' UNIX like 
(installation under the console), but graphical.

      I've spend some time on this matter, and see that Autopackage have 
something do said, but cannot a final job.

      For a while, I think on something like 'grpm' to install both 
packages like 'grpm file1.rpm file2.rpm', as well autoinstallable, but 
when we speak about graphical we are opening a door on what graphical.

     ... And this means: Tcl/Tk, Java, Qt/KDE, PyQt/PyKDE, Gtk/GNOME, 
PerlGtk and some other aleph.

     So, we can have packages like OpenOffice-2.4.tk.grpm

     Comments are welcome ... also on this mailing place. LSB need to 
upgrade but the new packager must be released so people can evaluate.


> 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
> ------------------------------------------------------------------------
> _______________________________________________
> lsb-discuss mailing list
> lsb-discuss at lists.linux-foundation.org
> https://lists.linux-foundation.org/mailman/listinfo/lsb-discuss

More information about the lsb-discuss mailing list