| 1 |
On Sun, Sep 8, 2013 at 8:06 PM, Ryan Hill <dirtyepic@g.o> wrote: |
| 2 |
> You will be expected to fix them, and `append-flags |
| 3 |
> -fno-stack-protector` is not an acceptable fix. You can't champion for more |
| 4 |
> secure defaults and then just disable them when they get in your way. |
| 5 |
|
| 6 |
Why not? Surely a system where 99.9% of the packages installed are |
| 7 |
hardened is more secure than a system where 0% of the packages |
| 8 |
installed are hardened. |
| 9 |
|
| 10 |
> So does anyone have any objections to making -fstack-protector the default? |
| 11 |
> Now is the time to speak up. |
| 12 |
|
| 13 |
So, in this world of all-or-nothing we want people who realize that |
| 14 |
100% protection might not be possible to raise an objection so that we |
| 15 |
end up with 0% protection instead? |
| 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 |
Archives