At 10:47 PM +0200 4/18/08, Jeremie Le Hen wrote:

This is a big-enough change that we should ease into it, as Max suggests. It can be very painful to back out of this, so we don't want to rush into the change and then find out that we really really regret it.

You've probably described this somewhere, but let me ask for a little more info.

There is "enabled" in the sense that the symbols exist in libc, so programs *can* be compiled with -fstack-protector-all or -fstack-protector options. But nothing much really happens until we start building programs with those options turned on. Once a program is built with one of those options, then that program has code in it which will check for stack-smashing in that one program.

So, in my mind there's the step of "enabling SSP", and then there's the step of "compiling programs with stack-protection on". I think we could also split that the second step in stages:

a) add stack-protection to all setuid programs in the base system. b) add stack-protection to all "/usr/sbin" programs in the base. c) add stack-protection to all programs in the base. d) compile ports with stack-protection on.

Is that a reasonable breakdown? We could (perhaps) have four switches, and people could turn on whatever wants they wanted. But as far as the *default* values, we might want "class A" to default on for 8.0-release, but the other classes to default off. Then (maybe) add another class each time we make another release.

I would agree that a phased approach to enabling SSP is warranted but I believe it should wind up enabled by default in -current fairly rapidly. Once the Project has gained more familiarity with SSP and its impacts, a decision can be made as to whether it should default to on or off in -stable and releases.