Hi,
On Sat, 20 Nov 2010, Raphael Hertzog wrote:
> I would really like Debian to build hardened binaries by default and it
> would be great if the switch could happen early in the wheezy cycle. For
> this I think we need to have a clear plan and I hope the technical
> committee can bring some clarity here. Either by overruling the GCC
> maintainer or by designing the missing pieces so that we can at least go
> forward (I would implement what's needed in dpkg-dev if I knew what's
> needed).
So we just had some discussion with Steve Langasek, Ian Jackson, Bdale
Garbee, me and Matthias Klose on this topic. I'll try to summarize the
outcome here. It's probably a good idea to be familiar with the
current dpkg-buildflags features before reading this mail, so check
"man dpkg-buildflags" if needed.
The consensus seems to be that we do not want to take the "gcc patch"
approach and thus we're not going to overrule the maintainer. The bulk
of the discussion then drifted on deciding how (hardening) build flags
should be injected in the package build process.
We evaluated how dpkg-buildflags can be used for this. For most
autoconf/automake-based build systems there are 2 ways to inject flags:
1/ On the ./configure command line:
./configure --with-foo CFLAGS="..." LDFLAGS="..." ...
2/ In the environment
The first form seem to be preferred but both approaches work and should be
properly supported. However dpkg-buildflags does not easily support the
former approach. This is something that should be fixed.
TODO: implement "dpkg-buildflags --export=configure" that outputs
“CFLAGS="…" LDFLAGS="…" ...” so that a maintainer can do
./configure --with-foo $(shell dpkg-buildflags --export=configure)
Also up to now, dpkg-buildflags has only been designed to return the
default build flags and it was my expectation that maintainers would
tweak its output should this be necessary (either to add flags or to
drop them, etc.).
Unfortunately recent experience proved that dpkg-buildflags is likely to
be called by various helpers and thus not in direct control of the
maintainer via the rules files (unless all the helper provide their own
way to do this but we really would like to avoid having severals ways
to do the same thing). The current git version of dpkg already has support
for debian/buildflags{,.<arch>} to allow maintainers to post-process
the resulting buildflags but while this interface works for 95% of the
easy cases, it can't cover them all because we have stuff like packages
doing several builds of the same code with different build options (for
example -Os for udebs) or adding flags depending on which compiler is
actually in use. So the correct interface to feed post-processing
instructions to dpkg-buildflags is environment variables (because this way
we can call dpkg-builflags multiple times with different values to the
environment variable as part of the debian/rules logic).
TODO: revert debian/buildflags support, and implement
support for the environment variable DEB_<flag>_MAINT_<operation> which
work exactly like the corresponding DEB_<flag>_<operation> except it's
meant to be used by the package maintainer within debian/rules.
Another limitation of dpkg-buildflags thas has been brought up is that
it only allows to append build flags and not to drop them. While it's
often possible to disable some option by providing the opposite option
later on the command line (e.g. "... --foo ... --no-foo"), it has been
pointed out that the possibility to drop them is useful in particular when
you would like to use another compiler that doesn't understand the
option in question. Also it's cleaner as the resulting command line is
shorter and more readable.
TODO: add a "STRIP" operation to the set of operations supported by
dpkg-buildflags. DEB_CFLAGS_MAINT_STRIP="--foo --bar" would basically
drop all occurrences of --foo and --bar in the returned build flags.
QUESTION: Is this ok to assume that all build flags can be "delimited"
by a space character?
Assuming that all those improvements are done, the consensus was that
it's fine for dpkg-buildflags to start emitting the hardening build
flags by default. According to Ubuntu's experience only a few dozen of
packages are broken by the presence of these flags and those packages
should just be updated to use the new STRIP operation to drop the
problematic flags. This could be dealt as part of a wheezy release goal.
Obviously those new flags will only be picked by packages already using
dpkg-buildflags but that already includes packages using "dh" since it uses
dpkg-buildflags to set the corresponding environment variable and
also packages using CDBS (AFAIK). The other remaining packages would have
to be updated by hand (and could also be part of a release goal).
The discussion mainly covered automake/autoconf-based build systems and
obviously there are some packages using alternate build systems where
this out-of-the-box support by dh/CDBS will not be enough. In those cases,
it's still up to the maintainer to adapt whatever is needed to feed
the build flags in the appropriate way.
Hopefully I have not forgotten anything important and I have correctly
summarized the whole discussion (which was rather dense for a 1h
discussion).
Cheers,
--
Raphaël Hertzog ◈ Debian Developer
Follow my Debian News ▶ http://RaphaelHertzog.com (English)
▶ http://RaphaelHertzog.fr (Français)
Attachment:
signature.asc
Description: Digital signature