[ubuntu/jaunty] conntrack 1:0.9.7-1.1ubuntu1 (Accepted)

[James Westby]

On Sun, 2008-11-23 at 16:31 -0800, Kees Cook wrote:
> Hi,
> 
> On Mon, Nov 24, 2008 at 12:15:13AM -0000, Manny Vindiola wrote:
> > conntrack (1:0.9.7-1.1ubuntu1) jaunty; urgency=low
> > 
> >   * Merge from debian unstable (LP: 256380), remaining changes:
> >     + #include <limits.h> in {main,ignore_pool}.c to get PATH_MAX and INT_MAX
> >     + local.c: Fix insecure printf usage
> >     + debian/rules:
> >       -undef _FORTIFY_SOURCE so that it doesn't fail about ignored chdir()
> >       return value.
> 
> Undefining FORTIFY should only be done in extreme cases when it is not
> possible to correct the situations it helps detects.  As documented[1], it
> is much better to check the ignored return values, and handle them in some
> graceful way, instead of disabling FORTIFY for the entire build, as this
> will leave the program without the run-time protections FORTIFY provides.
> In situations where it is not obvious how an error can be handled
> correctly, tricking the compiler into throwing away the return value is
> still preferred to disabling FORTIFY globally for the build.  (And in all
> situations, the changes should be forwarded to the Debian bug tracker.)

Hi Kees,

Thanks for bringing this up.

For the record Manny didn't introduce this change, just merged it. I
appreciate you raising the issue, and I know you weren't attacking 
Manny.

I have attacked a couple of these failures recently, and the thing I
always find hard is knowing what to do with an error condition. Without
knowing the code it is hard to know how an error should be handled.
For instance today I was looking at an ircd that wasn't checking the
return code on a write call, writing to its log file. I don't think
an error should abort, but in many cases that will be the only sensible
thing to do.

Are there any guidelines for how to handle these failures so that we can
get better at fixing them?

Thanks,

James