FORTIFY build failures (was: Re: [ubuntu/jaunty] conntrack 1:0.9.7-1.1ubuntu1 (Accepted))

[James Westby]

On Sun, 2008-11-23 at 17:47 -0800, Kees Cook wrote:
> Well, as you say, it's always different.  The way I've tended to triage
> them is:

This is good advice, do you think it should go on the wiki page?

> - If there is are obvious error handlers in near-by code, emulate them.
>   That's what I did in my suggested patch to conntrack[1].  This is,
>   obviously, the preferred method of dealing with it.

Yes, I've unfortunately tended to look at packages that have next to no
error handling, so there is no existing code to go off.

> - If there isn't an obvious way to handle the error, then stubbing out an
>   empty handler is the next way to go -- fundamentally, this doesn't
>   improve (or weaken) the quality of the code -- ignoring the return code
>   is what's already happening, so this doesn't change anything.  However,
>   what it _does_ do, is allows the FORTIFY option to still be enabled,
>   which means the program will gain the run-time FORTIFY protections.

Ah, there are runtime protections as well as code checks, now I see the
point.

> Also, in situations where you've had to disable FORTIFY (#3, #4), please
> document the issue in the CompilerFlags[3] wiki page (preferably also with
> a bug).
> 
> And thank you to everyone who has had to deal with the fall-out of these
> options!  I know they can really be an annoyance, but taken as a whole,
> Ubuntu is far better off with these flags enabled, and everyone's code
> quality goes up.  :)

Thank you for taking leadership in these issues. While the benefits are 
clear it's hard to enable things like this because of exactly these 
sorts of issues, so I appreciate your effort to improve things.

Thanks,

James