[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 3.8 beta requests



On 8/22/05, dick_(_at_)_uchicago_(_dot_)_edu <dick_(_at_)_uchicago_(_dot_)_edu> wrote:
> i think having a flag you could set to disable the new
> behavior would be a good idea. it may very well be that what i
> suggest is not doable due to the low-level nature of the
> functions in question. just a thought.

To complement the previous arguments against adding more knobs,
toggles, switches and crap:

"Security only works if the secure way is also the easy way." Notice
that every production security technology openbsd includes a) is easy
to use and b) is on by default. OpenSSH, privsep, strong random
numbers, strong crypto... you have to try weaken your system.

As others have said, other security technologies have failed/are
failing/ are not properly used because they're a) hard to use properly
and b) easy to not use. I'll admit it: I'm lazy. Once upon a time a
port that I used was broken by an openbsd security technology. I was
too lazy to track down the breakage, so I uninstalled the port and
went with pretty similar functionality in the base system.

Once upon a time there was a program that I used that was unreliable.
It crashed, hung, busy waited, etc. for no good reason. I crashed it
on openbsd a few times, found the bugs, and reported them (with
patches) to the author. Now it's stable.

As Theo and others will no doubt tell you the right thing to do is fix
the buggy program, rather than running a provably buggy program with
significant memory management issues. Now did you notice how Theo said
that the new mmap, guard pages, and other things stomp on errors as
small as a single byte. Remember that ssh bug? That was a one byte
overflow. Explain to us why turning off the security systems to keep a
buggy program from being terminated is a good thing?

CK

-- 
GDB has a 'break' feature; why doesn't it have 'fix' too?



Visit your host, monkey.org