Re: think twice before enabling -D_FORTIFY_SOURCE=2 for C projects without thorough build-time testing
On Fri, 20 Sep 2013, Daniel Pocock wrote:
> On 20/09/13 22:09, Bastian Blank wrote:
> > I would call code that hits such clear definitions too buggy to be
> > supported.
>
> and what if many more existing packages are found to have similar issues?
IMHO: fix everything gcc, llvm and the static testers complain about (which
can be quite troublesome, as you must be *sure* you're actually fixing the
issue instead of making it worse by silencing the warning without fixing a
real bug). And never mind the amount of false positives, which you also
need to make sure are actually false :( If you cannot do it, bug upstream
until they fix it.
I'd also manually check every instance of (at the very least) memcopy,
*printf, and friends, and run a batch of tests (i.e. use the program) under
valgrind and other such dynamic behaviour checking tools.
And if you find out it is too buggy to live, well, do the right thing and
kill it from Debian (or punt it to experimental) until it gets better.
> One of my packages has some nice colours:
>
> http://debile.debian.net/source/fred/resiprocate/1.8.12-4/1
I'd recommend checking manually either all or a decent group of the issues
related by those tools (some are really prone to false positives), and if
the issues are not false positives, I'd say take it upstream ASAP.
IMHO, in that case you should also nuke it from Debian jessie until the code
gets a really through check against incompetent[1] coding. A SIP stack is
very security sensitive... if upstream doesn't know enough C to refuse code
that depends on undefined behaviour, that cannot end well.
[1] no derision intended: the amount of pitfalls in the C standards makes it
*really hard* to be competent at coding in C.
--
"One disk to rule them all, One disk to find them. One disk to bring
them all and in the darkness grind them. In the Land of Redmond
where the shadows lie." -- The Silicon Valley Tarot
Henrique Holschuh
Reply to: