[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:
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
> 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
> I personally have chosen to abandon the existing *.rpm format and move to
> using XAR @rpm5.org largely because (imho) the existing implementation
> 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
> 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
> 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
> 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,
> 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
> 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
> 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
> The flaw is also directly pertinent to Ted T'so's claim that
> "everyone supports the RPMv3 format ... and that is indeed a GOOD
> 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
> packages (largely because of crypto == munition circa 1997) is the
> 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
> 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
> effort involved with "uplifting". Note that I would be perfectly willing
> to write the document, and handle additions, etc. But I'm certainly
> 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
> 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
More information about the lsb-discuss