Re: Enabling hardened build flags for Wheezy
* Charles Plessy <plessy@debian.org> [120430 16:26]:
> If people who are interested by improving our dozens of thousands upstream
> makefiles could spend time forwarding patches upstream by themselves, that
> would be appreciated. I have a hard time finding convincing words when I think
> the patch is borderline useless.
What are you talking about? Sorry, but I really cannot make any sense
out of that.
Let me try to explain the situation, so you can tell me where you
disagree:
We want some options enabled in as many package builds as possible.
Options that have not been the decade long defaults in compilers, so
they break a significant amount of software.
Changing the compiler defaults would have the side effect of also
affecting users and forcing all packages to cope with the changed
defaults at once. (And the packages having the hardest to fix issues
are usually the packages with the most absurd build systems, so
having to fix all of them to include compiler options disabling the
hardening flags is not that easy).
So instead of an opt-out by changing what the compiler does by default
and forcing the package maintainer to override them, we have a opt-in
system: the maintainer can give the options to the build system.
For that there is the new dpkg-buildflags command, that outputs all
categories of flags a package maintainer would want to have: It give
you preprocessor flags, it gives you C compiler flags, it gives you C++
compiler flags, it gives you fortran compiler flags and it gives you
linker flags. By default it gives some default hardning flags but also
supports the maintainer requesting more intrusive flags or disabling
some classes of flags (see the discussion of DEB_BUILD_MAINT_OPTIONS
in dpkg-buildflags manpage). It's also done in a way that support for
'noopt' it automatic, so it even makes it even less work for the
maintainer.
To ease it for package maintainers, the flags dpkg-buildflags generates
have the names the GNU coding standards request all package build
systems should support. As those are quite influental, many build
systems name them this way. And as they are split into the flags the
different tools want to have, every other scheme can be computed out of
those easily by just appending those set of flags you need.
If you have a build-system that does not support passing flags to the
compiler, then you won't get support for hardning with this opt-in way,
of course. But such a package would also have no way to override a
specific set of hardening flags, so it would have problems with the
opt-out way to, because it cannot opt-out.
As not everyone build systems has the same names for variables holding
the compiler (meaning preprocessor/actual compiler/linker) flags.
There is not even theoretically (compare "halting problem") a way to
determine what the variables are named like and what content they
expect. This simply needs a human to look at it and say which flags
need to be put where so that the upstream build system will pick them
up.
If a build system does not support passing flags to the compiler, and
you want it to have hardening flags, that might need some makefile
patches. But if there is no time for this or this is too complicated,
then one can just do without, generating a package without hardening
(and most likely also without support for noopt and the like, so do
not suppose other people will be extremly willing to help you fix the
bugs in it), but so be it.
The release goal is
"This goal is to update as many packages as possible to use security
hardening build flags via dpkg-buildflags. These flags enable various
protections against security issues such as stack smashing, predictable
locations of values in memory, etc."
It's not
"Every package even if only hardly being of a quality to be included in
a distribution must support hardening flags or it must be removed from
Debian".
Bernhard R. Link
Reply to: