Re: Lintian warning: hardening-no-fortify-functions & version numbering
2012/6/25 Ben Hutchings wrote:
>> BTW, it's interesting that Fedora/CentOS use -Wp,-D_FORTIFY_SOURCE=2
>> and they use it in CFLAGS/CXXFLAGS.
>
> Presumably as a workaround for build systems that do not respect
> CPPFLAGS.
I actually noticed that because it's "-Wp,-D...", not "-D...". But I guess
you're right, it's in CFLAGS because many build systems support CFLAGS,
but only autotools support CPPFLAGS.
> GNU make's implicit rules use CPPFLAGS. If other build systems or
> overriden rules don't use it, it's a bug. This can of course be
> worked around in debian/rules.
Well, such argument can be applied to any build system. For example: Cmake
uses CMAKE_C_FLAGS, but GNU's make does not use it. It's a bug. GNU make
must use CMAKE_C_FLAGS. And dpkg must set it too. Even more, dpkg should
set only CMAKE_C_FLAGS, CMAKE_CXX_FLAGS and CMAKE_SHARED_LINKER_FLAGS.
Yes, this may create some problems for people packaging autotools, but
this can of course be worked around in debian/rules.
Come on. :) How many build systems except autotools are using CPPFLAGS?
cmake, qmake, imake, nmake? It looks completely autotools-specific to me.
And forcing it is no better than forcing qmake DEFINES or CMAKE_C_FLAGS.
It just adds more work to packagers, but makes nothing better.
Talking just about autotools:
* CPPFLAGS without CFLAGS are used only by ./configure script
* CPPFLAGS without CFLAGS are used only for some conftests
* -D_FORTIFY_SOURCE=2 means nothing for those tests
* -D_FORTIFY_SOURCE=2 does nothing at all without -O2
So even for autotools there's no reason to keep -D_FORTIFY_SOURCE=2 in
a CPPFLAGS variable. It can be easily dropped.
Also dropping CPPFLAGS would also allow:
1. Use same rules for cmake and autotools packages.
2. Make every rules file a few lines shorter, thus a bit faster to build
3. Make "Hardening" wiki page shorter
4. Reduce the number of workarounds by one
5. Reduce the number of things people need to think about when packaging,
making packaging a little bit easier.
And no disadvantages on the other hand. :)
If it's not fixed in dpkg, as you said, it can be worked around in
debian/rules. I'm just trying to avoid adding unnecessary workarounds
to debian packages.
--
Serge
Reply to: