måndag 09 september 2013 21.00.12 skrev Ryan Hill: > On Mon, 9 Sep 2013 08:21:35 -0400 > > Rich Freeman wrote: > > On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill wrote: > > > So does anyone have any objections to making -fstack-protector the > > > default? > > > Now is the time to speak up. > > > > So, in this world of all-or-nothing we want people who realize that > > 100% protection might not be possible to raise an objection so that we > > end up with 0% protection instead? > > No, all I've heard so far is support and wanted to give anyone with an > opposing viewpoint a chance to speak up. I support it, but if there are > any problems we might run into it's best we know about them beforehand, no? > I wasn't looking for a reason to veto it. > > > Why not just do the sensible thing (IMHO) and make it a default, and > > then if it doesn't work for an individual package deal with it on an > > individual basis? We already encourage maintainers to try to get > > custom CFLAGS to work when practical, but when not practical we filter > > them. I don't see stack protection as any different. If there is a > > fix, then fix it, and if not, then disable it. I don't see a lack of > > stack-protection as a reason to keep something out of the tree. > > Rich, that's exactly what I'm saying. > > We have to make an effort to fix things properly, like we do with any > supported feature. That's something I see as one of the key strengths of > this group we have. Obviously there are cases where a fix isn't possible > (glibc and gcc itself are prime examples) and we need to disable it. > That's fine. But we need to discourage people sweeping problems under the > rug because they're inconvenient, especially when those problems may > indicate security issues. > > I'm just trying to set proper expectations - that this change may break > people's packages, and they may have to do some work to find out why and how > to fix it. I don't like creating more work for people, so I want to be > sure there is consensus on this first. So far it sounds like there is. I did build most of the packages (~14000 packages) in tree when we move from gcc 3.X to 4.X with stack protection and some packages didn't work but we fix it or added work work arounds to them. So in short most of the package work is allready done. /Magnus