[hardening-discuss] Bug#489771: support for centralized control over hardening-wrapper options

[Raphael Hertzog]

On Mon, 21 Jul 2008, Kees Cook wrote:
> Well, the original goal was to move the hardening option knowledge out
> of hardening-wrapper and into dpkg-buildpackage, so this was designed to
> be a migration path.

Why do we need a migration path and not a direct migration ? Since
hardening-wrapper does nothing without environment variables and since
dpkg-buildpackage already provides default values to compiler flags...
what would be the required intermediary step between: "hardening-wrapper
does the job" and "dpkg-buildpackage does the job" ?

> Since dpkg-buildpackage is setting the default compiler flags (-g -Wall,
> etc), this seemed like a sensible place for the other distro-wide flags
> to go live so we can get rid of the crazy hack that is
> hardening-wrapper.  :)

Indeed. But your patch was not changing the distro-wide flags. :)

> > Note that I'm not opposed to have dpkg-buildpackage enable hardening
> > by default in the future (by auto-setting the option unless instructed
> > otherwise by Build-Option: / DEB_BUILD_OPTIONS). For now, I just
> > want to not bloat dpkg-buildpackage with too much specific code like this
> > one and want to integrate this change in a more generic framework.
> 
> Sure, I can certainly understand that.  Will there be a framework that a
> compiler flag default option system can be plugged into?

I haven't thought about this yet. As you noticed, the framework I was
referring to was more for controlling DEB_BUILD_OPTIONS than for
controlling CFLAGS & all.

But, if someones comes up with a sensible design for such a framework,
I'm happy to give it a try. But I'm not sure if it would add any value
compared to some hardcoded rules to generate the compiler flags.

Cheers,
-- 
Raphaël Hertzog

Le best-seller français mis à jour pour Debian Etch :
http://www.ouaza.com/livre/admin-debian/