On 8/22/05, [EMAIL PROTECTED] <[EMAIL PROTECTED]> 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?
