Craig White wrote:
On Wed, 2005-10-12 at 14:18 -0500, Mike McCarty wrote:
When this was RHL, the operative phrase was always...it's not a bug if
it isn't in bugzilla
That amounts to a definition of the word "bug". But I don't use
that word. I use the word "defect". And defective software is
just that, defective.
----
I will repeat it just in case I didn't get through...
It's not a bug if it isn't in bugzilla
Oh, you got through. But I'm not sure that I made myself
quite clear. What the program putatively does is not something
I want done, anyway. So I don't care if it eats 100% of
the CPU when it runs, because it doesn't run on my machine
anymore. It's not in cron on my machine, you see. I stated
in my earlier message that IMO it should be removed from
cron. I didn't say it, but I'd think that reflection on that
might lead one to presume that I had done exactly that.
My commentary was not about the tool, it was about the
attitude of RH putting in a tool as part of the normal
load which munges executables periodically. Even if it made
them load faster (which so far is undemonstrated to me)
and even if it didn't eat the machine for extended periods
of time (which has been amply demonstrated to me), I would not want it
to run. Precisely because of "unintended side effects" which
are inherently possible when modifying a program.
How can prelink know that the information that the person put into
his executable and which the tool is modifying isn't something
the builder desperately wanted in there, unchanged?
Answer: It can't.
And any time an executable gets modified, it gives me the willies.
Every defect in prelink becomes a defect IN EVERY PROGRAM ON MY MACHINE.
It makes the use of ls a potentially dangerous act.
It's not a good thing.
The concept itself is flawed.
It doesn't need repair; it needs to be removed from the load. Or at the
very least be something which is an install option, along with a caveat
that it may make programs load faster, but also may make every program
on the machine be defective. And if it were described in that way, I
suspect most people would not install it. And that is my view of the
program. It may make my programs load faster, and it may make them
defective. I don't want it.
And we have a possible example of where prelink *did* remove information
which was important.
If it has *security* benefits (as hinted at by Ulrich Drepper), they
aren't documented. If they were documented, I'd want the documentation
to specify precisely what attacks are defended against, under what
circumstances those attacks might occur, how the modification
helps to defend against them, and what possible side effects there
might be as a result of running prelink.
One *known* effect (not a side effect) is that the binary you execute is
not the binary which went through QA.
Mike
--
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
This message made from 100% recycled bits.
You have found the bank of Larn.
I can explain it for you, but I can't understand it for you.
I speak only for myself, and I am unanimous in that!
