Integration of ProPolice in FreeBSD

[Garance A Drosehn]

At 11:37 AM +0200 4/19/08, Jeremie Le Hen wrote:
>
>On Fri, Apr 18, 2008 at 08:37:24PM -0400, Garance A Drosehn wrote:
>  >
>>   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.
>
>On Sat, Apr 19, 2008 at 05:14:00PM +1000, Peter Jeremy wrote:
>  > 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.
>
>Provided the very little performance overhead [1], my leaning goes
>toward Peter here.

My comment was talking about how we would roll out SSP for *releases*.
I do agree we'd move faster for having developers test it in -current.

>Moreover given that some ports simply don't compile with SSP (qemu,
>gcc4, etherboot), my personal opinion is it should be enabled by
>default for ports on -CURRENT in order to spot those out.

This part I'm not so sure of.  The fact that I'm willing to run
freebsd-current to test *freebsd* changes does not mean that I want
to be constantly tripping over port-specific problems.  I realize
that SSP is certainly useful for ports, but that's > 15,000 programs
which we probably have little control over.  It's going to take quite
awhile before we get that sorted out.

I guess I don't have any specific recommendation for how to handle SSP
in the ports collection.  Maybe per-port settings, although that would
also get messy.  The main ports-developers should decide how SSP should
be rolled out through the ports collection.

-- 
Garance Alistair Drosehn     =               drosehn at rpi.edu
Senior Systems Programmer               or   gad at FreeBSD.org
Rensselaer Polytechnic Institute;             Troy, NY;  USA