Bug#796562: lintian: Please identify lack of sanitation compiler/linker flags
Control: tags 1 + moreinfo
* <intrigeri@debian.org>, 2015-08-22, 18:00:
we now have dpkg-buildflags(1) to turn on various sanitation
compiler/linker flags, such as -fsanitize=address.
Usage of such flags is not widespread yet in the Debian archive, but my
first attempts at using them on a few packages revealed bugs (some of
which, with potential security implications). It would be good to have
Lintian point maintainers at these flags, so that they learn about
them, try them out, and possibly discover security issues.
Could you clarify what exactly you want Lintian to check for?
I you meant to say that you think that all packages should be built with
-fsanitize=address, and Lintian should complain about binaries that
weren't compiled that way, then I disagree. On the contrary, I think we
shouldn't ship binaries built with with ASAN enabled, except maybe in
special cases, for a variety of reasons:
* ASAN makes the binaries much slower.
* ASAN makes the binaries much bigger.
* ASAN is only reliable if the whole program was compiled with
sanitization enabled (including shared library packages);
* If a shared library was compiled with ASAN, then every program
(directly or indirectly) linked to it must be also compiled with ASAN.
* ASAN is a virtual memory hog. It's very difficult to use "ulimit -v"
against a program that was built with this option.
* Address sanitizer can change behavior of correct programs. For
example, by default malloc() returning NULL is a fatal condition.
--
Jakub Wilk
Reply to: