[lsb-discuss] LSB format packaging and security

[Jeff Johnson]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.linux-foundation.org/pipermail/lsb-discuss/attachments/20080420/51d3e21e/attachment.htm