| 1 |
On Mon, 9 Sep 2013 08:21:35 -0400 |
| 2 |
Rich Freeman <rich0@g.o> wrote: |
| 3 |
|
| 4 |
> On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@g.o> wrote: |
| 5 |
> > So does anyone have any objections to making -fstack-protector the default? |
| 6 |
> > Now is the time to speak up. |
| 7 |
> |
| 8 |
> So, in this world of all-or-nothing we want people who realize that |
| 9 |
> 100% protection might not be possible to raise an objection so that we |
| 10 |
> end up with 0% protection instead? |
| 11 |
|
| 12 |
No, all I've heard so far is support and wanted to give anyone with an opposing |
| 13 |
viewpoint a chance to speak up. I support it, but if there are any problems we |
| 14 |
might run into it's best we know about them beforehand, no? I wasn't looking |
| 15 |
for a reason to veto it. |
| 16 |
|
| 17 |
> Why not just do the sensible thing (IMHO) and make it a default, and |
| 18 |
> then if it doesn't work for an individual package deal with it on an |
| 19 |
> individual basis? We already encourage maintainers to try to get |
| 20 |
> custom CFLAGS to work when practical, but when not practical we filter |
| 21 |
> them. I don't see stack protection as any different. If there is a |
| 22 |
> fix, then fix it, and if not, then disable it. I don't see a lack of |
| 23 |
> stack-protection as a reason to keep something out of the tree. |
| 24 |
|
| 25 |
Rich, that's exactly what I'm saying. |
| 26 |
|
| 27 |
We have to make an effort to fix things properly, like we do with any supported |
| 28 |
feature. That's something I see as one of the key strengths of this group we |
| 29 |
have. Obviously there are cases where a fix isn't possible (glibc and gcc |
| 30 |
itself are prime examples) and we need to disable it. That's fine. But we |
| 31 |
need to discourage people sweeping problems under the rug because they're |
| 32 |
inconvenient, especially when those problems may indicate security issues. |
| 33 |
|
| 34 |
I'm just trying to set proper expectations - that this change may break |
| 35 |
people's packages, and they may have to do some work to find out why and how to |
| 36 |
fix it. I don't like creating more work for people, so I want to be sure there |
| 37 |
is consensus on this first. So far it sounds like there is. |
| 38 |
|
| 39 |
|
| 40 |
-- |
| 41 |
Ryan Hill psn: dirtyepic_sk |
| 42 |
gcc-porting/toolchain/wxwidgets @ gentoo.org |
| 43 |
|
| 44 |
47C3 6D62 4864 0E49 8E9E 7F92 ED38 BD49 957A 8463 |
Archives