From: Jeff Johnson <[EMAIL PROTECTED]>
Date: April 20, 2008 11:21:10 AM EDT
To: [EMAIL PROTECTED]
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
