On Wed, May 12, 2010 at 8:20 AM, Andreas Radke <[email protected]> wrote: > Am Wed, 12 May 2010 11:14:48 +0200 > schrieb Thomas Bächler <[email protected]>: > >> > So, do I really have to wait until that is fixed before we can >> > discuss _future_ changes?
+1 from me, especially if we aren't the first distro to jump into this so we aren't going to hit loads of roadblocks. Let's make sure we have a standard way of turning it off for packages that do break, however. >> I think I was already in favor of using the stack protector a year >> ago. Actually (I already mentioned this last time this discussion >> came up) we have built our kernels with the stack protector enabled >> for a long time >> - to be precise, it was enabled on June 11th when we switched to >> 2.6.30. >> > > There's a kernel configuration option for this. > > I'm not sure if we should change our compiler flags just prevent > applications to fail. Is this the task of a compiler to be a 2nd stage > protector for poorly written apps? > > I can imagine such a safety option enabled in a security critical > distribution like firewalls. > > But for the rest wouldn't adding such a feature take the pressure from > the coders to produce proper code? I think the overhead is something > I wouldn't like to see in ArchLinux. At least as long as this can't be > switched off at runtime by the user. This isn't some -fix-all-your-code option. It *will* make things crash if there are buffer overflows. It doesn't magically prevent them from happening. That to me would be incentive enough if I was coding upstream to fix my software. I'd also like to think we aren't Gentoo either and do care a decent amount about security. If this prevents a vulnerability from affecting us, we've made a good choice that 1% overhead is probably not going to kill us. -Dan
